17 puntos por GN⁺ 2025-07-25 | 1 comentarios | Compartir por WhatsApp
  • La mayoría de las herramientas de IA actuales no reflejan los procesos de aprendizaje centrados en las personas (recuperación, ejecución e iteración colectiva); en última instancia, esto es un diseño inverso que arruina el ciclo de crecimiento tanto humano como de la IA
  • Las personas aprenden no solo conocimiento, sino también procesos, e innovan mediante iteraciones colectivas y acumulativas. Sin embargo, la mayoría de las herramientas de IA siguen el patrón de “clic en un botón → la IA lo resuelve sola”, y eliminan el ciclo de recuperación y aprendizaje liderado por la persona
  • Una herramienta de IA deseable debe inducir la participación activa y la recuperación del usuario en las etapas de “Explicar → Demostrar → Guiar → Potenciar (Explain, Demonstrate, Guide, Enhance)”, y debe apuntar no a la automatización sino a la amplificación
  • Ejemplo: en una herramienta de observación/recuperación, en lugar de que la IA actúe de inmediato, debe cumplir un rol que promueva el pensamiento y el aprendizaje humano en cada etapa, como explicar el proceso, orientar acciones, guiar la resolución de problemas y sugerir mejoras posteriores
  • Si estos patrones centrados en las personas se consolidan, será posible un bucle de retroalimentación positivo en el que el crecimiento del conocimiento colectivo y la calidad de la IA se fortalezcan mutuamente, lo que puede traer innovación a todo el ecosistema de herramientas de sistemas

Introducción: el problema esencial del aprendizaje humano y las herramientas de IA

  • Las herramientas de IA no se están construyendo para apoyar la colaboración y el aprendizaje humano, sino de una manera ineficiente y en sentido inverso
  • En lugar de fortalecer las capacidades humanas, las herramientas se diseñan de forma que obstaculizan el pensamiento crítico y la resolución de problemas
  • Esta situación ya está produciendo efectos contraproducentes visibles, y hace falta cambiar hacia un enfoque más eficaz

Limitaciones de las herramientas de IA actuales: desarrollo al revés

  • La gran mayoría de las herramientas de IA actuales sigue este patrón
    • Clic en el botón de IA → resultado inmediato como por arte de magia
    • Visualización de datos y sugerencias de la IA
    • Prompt simple y ejecución automática
  • Este enfoque omite el ciclo de aprendizaje clave de las personas: definición del problema, memoria, recuperación, aprendizaje del proceso, transmisión del conocimiento y mejora iterativa
  • La IA intenta sustituir las fortalezas centrales del ser humano, y la propia IA también es débil en ese terreno
  • Como resultado, se deteriora la capacidad humana de pensar y resolver problemasse vuelve imposible generar datos de alta calidad (lo que también frena el avance de la IA) → se forma un círculo vicioso

¿Cómo aprenden las personas?

  • Según la teoría de Retrieval Practice, las personas no aprenden solo recibiendo información, sino mediante la recuperación activa
  • El verdadero efecto de aprendizaje surge no de memorizar pasivamente, sino del proceso de “sacar” la información directamente del cerebro
  • En el aprendizaje, lo más importante es adquirir procesos más que conocimiento aislado
    • Por ejemplo, al aprender panadería, es más efectivo aprender el procedimiento para hacer un pastel que memorizar los ingredientes
  • Por eso, un diseño práctico y centrado en procesos encaja mejor con las herramientas colaborativas

El principio de la innovación y del crecimiento colectivo

  • La esencia de la innovación no proviene de individuos que crean una tecnología completamente nueva, sino de la acumulación colectiva de pequeñas mejoras iterativas
    — la esencia no está en la creación genial de unos pocos, sino en el proceso por el cual varias personas superponen y mejoran conocimiento existente
  • Los seres humanos están mejor adaptados a la imitación, la repetición y la transformación de casos existentes que a la innovación aislada
  • La teoría del aprendizaje colectivo basado en el cerebro muestra que esta innovación colectiva es intrínsecamente adecuada para los humanos
  • En lugar de separar la resolución de problemas de la innovación, la capacidad para resolver problemas, difundir conocimiento y aprender en colectivo es el verdadero motor de la innovación
  • La clave es el aprendizaje centrado en procesos, el esfuerzo con dificultad adecuada, la repetición y el refuerzo colectivos, y una IA que asista a las personas
  • Las herramientas de IA deben ser “asistentes del pensamiento” para las personas, y no entidades que decidan por sí mismas o las reemplacen

Diseño correcto de la interacción con IA

  • La IA se parece más a un instructor muy olvidadizo que a un colega o un pasante
  • El objetivo de la IA es guiar al usuario para que aprenda por sí mismo y aprenda cómo aprender
  • Debe diseñarse para potenciar un proceso educativo eficaz (EDGE: Explain, Demonstrate, Guide, Enhance)
    • Explicar (Explain): guía del proceso, presentación de pasos omitidos, etc. (no solo “haz clic en este botón”)
      • Sugerir pasos faltantes
      • Proveer y explicar una guía del proceso
      • Enfatizar el proceso en el que la persona recuerda y ejecuta el proceso por sí misma
      • Mal ejemplo: ofrecer de inmediato un botón de “ejecutar”, tooltips de error y otros elementos que marginan el proceso de recuperación
    • Demostrar (Demonstrate): conversión de queries, demostración de UI, demos interactivas, etc.; no se trata de “ejecutar automáticamente”, sino de fomentar la participación
      • Convertir consultas en lenguaje natural a la sintaxis de consultas del sistema
      • Ayudar a navegar la UI (guiar directamente a la pantalla relacionada cuando se solicite)
      • Ofrecer demos cortas de 15 segundos o tutoriales interactivos
      • Evitar la “ejecución automática”: reduce la confianza, impide ajustes finos y debilita la capacidad humana
      • La IA también debe usar como material de aprendizaje los datos añadidos y los registros de recuperación humana (pairing, mentoría, etc.)
    • Guiar (Guide): inducir preguntas, discutir las partes problemáticas, elaborar planes de acción; usar preguntas y validación al estilo socrático
      • Si el usuario presenta un plan, sugerir la siguiente acción y ofrecer guía
      • Indicar la documentación necesaria, responsables del código y materiales relacionados
      • Fomentar modelos de observación/aprendizaje y la documentación
      • Validar respuestas, contrastar información y comprobar claridad
      • Mal ejemplo: dar soporte sin inducir respuesta, ofrecer demasiada información no solicitada, actitud autoritaria, o facilitar el abuso del botón de “continuar” por parte del usuario
      • Debe asistir sin interferir con la repetición del razonamiento racional humano
    • Potenciar (Enhance): sugerencias de mejora después de actuar, aprendizaje de patrones repetitivos, convertir registros reales en postmortems; ofrecer oportunidades sutiles de aprendizaje
      • Sugerir mejoras graduales justo después o durante una acción
      • Mostrar dinámicamente atajos o funciones adicionales para tareas repetidas
      • Sugerir mejoras al proceso mismo: mejorar pipelines de infraestructura, ajustar alertas, recomendar mejor instrumentación cuando se usa intuición, etc.
      • Promover el aprendizaje micro a través de registros posteriores al incidente (notas → material de aprendizaje) y observación
      • Mantener el centro del razonamiento humano e introducir de forma natural prompts que refuercen la recuperación, en vez de optimización automática
  • En particular, en cada etapa debe consolidarse una estructura en la que la persona recuerde, elija y ejecute, y la IA debe concentrarse en amplificar ese proceso
    • A partir de casos reales (herramientas de gestión de incidentes y observabilidad), se explican ejemplos de buenas interacciones con IA y anti-patrones en cada etapa

Principios generales

  • Reforzar continuamente el aprendizaje humano
  • Promover el trabajo en equipo: colaboración colectiva y compartición de información
  • En vez de automatizar el esquema “espacio en blanco → respuesta correcta”, acelerar la participación y ejecución del proceso (sin sustituirlo directamente con automatización)
    • Evitar “resultado inmediato desde la nada”
  • No buscar una “usabilidad sin esfuerzo”, sino herramientas que exijan un nivel adecuado de esfuerzo y participación
  • Apoyar que el aprendizaje y la experiencia del equipo se reflejen en los resultados

Buen ejemplo aplicado a la escritura de código: diseño “hacia adelante”, no “al revés”

  • En lugar de generar código directamente con IA,
    • redactar un documento inicial → diagrama de arquitectura → plan de pruebas → código de pruebas → código stub → generación de código
  • Después de validar el código, reorganizar en sentido inverso pruebas, documentación y arquitectura como parte del proceso completo
  • En cada etapa, dar importancia a preguntas y validación (refuerzo de la recuperación); no limitarse a preguntar sí/no cuando no es posible validar
  • Un enfoque de desarrollo basado en recuperación genera datos de aprendizaje y prueba de alta calidad, y también mejora el aprendizaje de la IA

Posibilidad de expansión cross-functional (no desarrollo, por ejemplo, soporte al cliente)

  • Ejemplo: en una interrupción operativa causada por un incidente, el equipo de soporte al cliente se comunica con el equipo de desarrollo a través de IA
    • La IA proporciona un primer borrador y, tras la validación del equipo de desarrollo, se mejora la precisión
    • Flujo de información en tiempo real entre varios equipos, como soporte y desarrollo, minimizando la carga del cambio de contexto
    • Sin interrumpir en exceso a expertos clave, y permitiendo comunicación mutua cuando sea necesario
    • La IA puede transformar fácilmente las respuestas técnicas contextuales del equipo de desarrollo en explicaciones comprensibles para el público general
  • Si esta estructura se hace realidad, podría maximizarse el aprendizaje colectivo y la eficiencia de colaboración dentro y fuera de la organización
  • También puede evolucionar hacia una herramienta de soporte/integración multinivel

Conclusión

  • Las herramientas de IA actuales se están desarrollando de una forma inversa que debilita la capacidad humana de aprendizaje colectivo iterativo y de resolución de problemas
    • Hace falta un cambio que enfatice el fortalecimiento de la colaboración y el apoyo a procesos liderados por las personas
  • Solo así será posible un círculo virtuoso en el que humanos e IA logren un crecimiento mutuamente amplificador
  • Al diseñar herramientas, no debemos olvidar que la persona no está simplemente “dentro del loop”; la persona misma es el loop
  • Ya es hora de exigir una innovación centrada en las personas en las herramientas de sistemas
    • Las herramientas de IA colaborativas, centradas en procesos y orientadas a la amplificación son la clave de la innovación

1 comentarios

 
GN⁺ 2025-07-25
Opiniones en Hacker News
  • Este texto tiene partes confusas. Parece que Weakly se refiere a agentes de programación más pasivos, que operan principalmente dando consejos, como si fuera el enfoque que antirez dijo preferir hacia 2025, pero en realidad está tratando agentes cuyo rol es investigar y resolver problemas operativos. El argumento de Weakly es que el agente debería ser como Clippy: solo aconsejar y dejarle el volante a la persona. Pero no veo qué valor tiene obligar a una persona a ponerse a revisar logs, buscar anomalías y formular hipótesis. Por la misma razón por la que una computadora juega mejor ajedrez, la IA es una herramienta inherentemente mejor que las personas para este tipo de tareas. Parece que Weakly traza una línea muy clara entre aconsejar y actuar de verdad, pero no creo que esa línea sea correcta. Claro, hay áreas donde no se le puede delegar ejecución autónoma total a la IA (por ejemplo, correr terraform apply), pero también hay muchas donde no hay razón para bloquearla. Al final, el objetivo de resolver incidentes es resolver el incidente

    • Todavía no existe una herramienta de IA que resuelva incidentes de forma satisfactoria. También está el tema de la responsabilidad, y para garantizar una ejecución correcta la intervención humana sigue siendo indispensable

    • El problema de fondo es si se le va a dar a la IA acceso al entorno real de operación. Viendo casos recientes donde una IA borró una base de datos incluso después de que se le dijo “no lo hagas” (porque la IA no siempre interpreta bien instrucciones negativas como not), la preocupación de seguridad en un entorno real es bastante seria

    • Me intriga hasta qué punto se le puede dar autonomía a un agente. Si hablamos de buenas prácticas de DevOps, la mayoría de los cambios deberían llegar a producción solo después de un commit de código o de ser promovidos por varios entornos. Y eso incluye no solo el código de la aplicación, sino también la infraestructura misma. En ese contexto, me pregunto hasta dónde sería razonable permitir ejecución autónoma del agente durante la respuesta a incidentes

    • Creo que depurar por cuenta propia también tiene cierto valor. Sobre todo si la meta es mejorar la habilidad de programar en sí. Siguiendo con el ejemplo del ajedrez, una IA como Leela o Stockfish puede analizar mucho más rápido y profundo, pero la mejora real viene de la experiencia de analizar posiciones por uno mismo. Incluso los jugadores profesionales practican tácticas repetidamente para seguir entrenando el cerebro. No sé bien si con IA y humanos juntos se aprende más rápido o si se aprende mejor de forma independiente. Y también tengo sentimientos encontrados sobre si esa capacidad seguirá siendo relevante en el futuro

    • Un punto importante en las discusiones sobre detección de anomalías y gestión de incidentes es que no todos los problemas son iguales, y muchos sí se pueden automatizar hasta cierto grado. La frontera entre cuándo pasarle un problema a un procesador cognitivo como una IA y cuándo debe intervenir directamente un ingeniero humano es clave. La IA es buena detectando patrones a gran escala, pero no siempre acierta al determinar si un patrón es realmente significativo. Claro, tampoco se puede asumir que una persona siempre vaya a cubrir esos huecos

  • Desde la perspectiva de herramientas/productos de IA, creo que el camino a futuro es ir hacia “Intelligent Workspaces”. Hay que salir del formato de simple chatbot
    Enlace relacionado
    En esencia, lo importante es un entorno/plataforma donde todas las configuraciones, palancas y controles sigan en manos humanas, pero con capacidades de IA integradas estrechamente. Esto es mucho más difícil que simplemente hacer un fork de VSCode

    • Un chatbot es muchísimo más fácil de implementar que un espacio de trabajo inteligente. Y la IA funciona bien incluso sin interacción humana. Me gustaría ver más variedad de interfaces para aprovechar IA que no sean chat

    • Últimamente he estado trabajando en proyectos con Claude Code, y me gustaría que mi instancia pudiera conversar y colaborar con la de otros desarrolladores. Puedo mantener documentación editando CLAUDE.md, pero sería genial si CC tuviera funciones de colaboración en equipo integradas. Si alguien tiene buenas sugerencias, que las comparta

  • Creo que este texto muestra bien por qué la innovación a menudo viene de gente externa. Se nota mucho que el autor tiene una trayectoria fuerte como manager de ingeniería o ingeniero principal en organizaciones grandes, y eso no conecta demasiado con mi experiencia. Me preocupa que, si este estilo termina consolidándose como la forma “correcta” de hacer tooling con IA, la IA quede estancada sobre ciertas suposiciones acerca del workflow humano. Llevo 15 años haciendo I+D de aplicaciones de ML de apoyo para expertos de dominio (no programadores), y mis principios difieren algo de los del autor. Que las perspectivas sean tan distintas demuestra que el espacio de diseño es muy amplio y que todavía es demasiado pronto para concluir que un enfoque específico es la respuesta correcta. Nadie sabe aún hacia dónde va a ir el tooling de IA

    • Claro, una interpretación posible es que los sistemas de ML que construí en estos últimos 15 años han estado nivelando o reemplazando capacidades humanas. Pero sí coincido en que la interpretación cambia según la posición desde la que uno mire. Aun así, me parece una buena práctica mantener al ser humano (y su conocimiento/capacidad de búsqueda) lo más posible en el centro del workflow
  • Algo que siempre me preocupa del coding con IA es que se vuelve más difícil mantener la habilidad. El acto de tipear código directamente —incluido el boilerplate— sí funciona como un entrenamiento tipo pintar la cerca de Mr. Miyagi. Gracias a esa práctica repetitiva, los patrones quedan muy grabados en la cabeza, y eso luego ayuda mucho cuando toca tomar decisiones de diseño de mayor nivel

    • Tecnologías anteriores (escritura, imprenta, etc.) quizá también redujeron la calidad de la caligrafía o de la retórica, pero a cambio amplificaron la capacidad de pensar. La idea de Steve Jobs del “bicycle-for-the-mind” es un buen ejemplo. Pero al aplicar esa lógica a la IA hay una diferencia: las tecnologías anteriores eliminaban cuellos de botella de distribución, mientras que la IA apunta directamente al proceso creativo mismo. En trabajo creativo, creo que usar IA solo es deseable en la medida en que no obstaculice el desarrollo de mi propia creatividad. El autocontrol y la autoconciencia humanas tienen límites

    • A menudo, por la noche o en la ducha, le sigo dando vueltas mentalmente a un problema y me imagino el “código”. Si las estructuras del lenguaje no estuvieran tan profundamente metidas en mi cabeza, esa programación imaginaria sería mucho más difícil

    • También se pueden encontrar ejemplos parecidos en la vida diaria:

  1. Ni recuerdo cuándo fue la última vez que escribí algo significativo a mano. Mi letra ya es un desastre
  2. Sin navegación no me animo a manejar buscando una ruta. ¿Leer mapas? Ya parece cosa de otro mundo
  • Hubo una época en la que se soldaban transistores a mano. Pero la tecnología ya avanzó tanto que hacerlo directamente como antes ahora se siente muy pesado. Así, mientras sigo ampliando y reduciendo el foco del pensamiento, todavía extraño programar de esa manera. Aunque igual sigo programando bastante

  • “Every augmentation is an amputation” - Marshall McLuhan

  • Por eso me gusta mucho Deep Research. Siempre empieza haciendo preguntas y me empuja a definir con más claridad qué es lo que quiero aprender. Siento que un simple cambio de UX puede marcar una gran diferencia entre ayudar a los usuarios de un servicio a aprender o hacer que dependan de la herramienta sin pensar críticamente

    • Pero, ¿de verdad te has fijado bien en esas preguntas? Deep Research a veces sirve, pero otras veces da la impresión de que esa “pregunta” se agregó solo para aparentar. Muchas veces vuelve a preguntar cosas que yo ya había redactado claramente con cuidado. No parece ayudar mucho al proceso real de búsqueda

    • Como redactor técnico, yo tiendo a no usar Deep Research. Más bien entorpece mi trabajo. El proceso mismo de investigar, tomar notas y resumir es lo que me ayuda a entender profundamente un tema. El documento final es solo el resultado de eso. Si la IA hace ese trabajo por mí, obtengo las notas, sí, pero no el mismo nivel de comprensión. Leer un documento escrito por IA no reemplaza la experiencia directa

  • Creo que este texto confunde el núcleo de la adopción de IA. El objetivo de adoptar IA no es volver más inteligentes a las personas, sino aumentar la productividad del proceso completo eliminando trabajo repetitivo donde la creatividad humana no recibe una recompensa significativa

  • En mi experiencia, las mejores formas de usar IA al programar son estas:

    • Como un find/replace avanzado, por ejemplo cuando quiero decirle “cámbiame todo esto por Y de una vez” en cosas como inicialización de structs. (Regex es demasiado pesado)
    • En procesos de trabajo con agentes, funciona mejor no tratarlo como si fuera una persona, sino darle tareas fragmentadas de más alto nivel paso a paso. En vez de “implementa la funcionalidad”, decir “crea un archivo nuevo y define funciones stub” → “empieza por la primera función y ponle comportamiento x” → “la segunda función primero llama a la primera y luego hace Y”
    • Para encontrar información en un codebase que no conoces o preguntar por una implementación específica. Algo como: “copilot, ¿dónde están definidas todas las rutas de la app?”. Es muy cómodo poder verificar rápido cosas que antes uno habría terminado preguntándole una y otra vez a la persona experta en IRC
  • Hace poco ayudé a mi padre a preparar una presentación. Él tiene suficiente información, pero como no es diseñador, le costaba hacer que las diapositivas se vieran bien. Probamos varias apps de IA para generar presentaciones, y aunque se veían llamativas, no ayudaban realmente con la “mejora de diseño” que el usuario quería. Al final concluimos que arreglarlas manualmente para que se vieran mejor era mucho mejor

  • Estoy totalmente de acuerdo en que el flujo de “empezar por arquitectura y diseño de pruebas y luego llevar eso al código real” fue 100% más efectivo. Solo cambiando hábitos de workflow ya se puede hacer, incluso sin herramientas aparte (aunque, claro, mejor todavía si hay herramientas dedicadas o prompts estándar)

    • Yo también necesitaba eso tanto que empecé a construir mi propia herramienta de arquitectura. Si se tiene una arquitectura constructiva, ya es perfectamente posible delegar la implementación a la IA actual. Eso sí, estas herramientas todavía son débiles para leer logs de procesos de larga duración como docker-compose. Y las tareas reales que hacen falta son las siguientes:
      • investigar el problema
      • describir la funcionalidad
      • definir el contrato de la API
      • redactar un plan básico de implementación
      • configurar autenticación/permisos
      • preparar estrategia de pruebas y setup/teardown eficiente
      • documentar librerías y buscar documentación oficial para la IA
      • además, la IA se equivoca seguido en cosas como import, y también es frágil con procesos de larga duración
    • Esto es tan esencial que la frase seguiría diciendo lo mismo incluso sin usar la palabra “vibe”
  • Los humanos somos una especie especialmente buena para la iteración acumulativa, es decir, la mejora continua. Por eso el brainstorming funciona tan bien en grupo. En psicología cognitiva incluso existen teorías de la “cultura” como aprendizaje colectivo acumulativo e innovación. Solemos decir que estamos “parados sobre hombros de gigantes”, y no es solo una frase bonita: así es como realmente funcionamos. La creatividad al final es búsqueda, y además búsqueda social. No se desarrolla solo dentro del cerebro, sino en la interacción entre cerebro y entorno, en capas sociales y culturales. Por eso no me preocupa si un LLM realmente “entiende”. Si busca, genera ideas y luego las valida en la práctica, para mí es suficiente. También creo que, más allá del sustrato, lo importante es la búsqueda misma. Aunque, claro, el sustrato puede cambiar el espacio de búsqueda al que se puede acceder