El humano en el loop está agotado

 (pydantic.dev)
2 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • La programación con LLM aumenta la productividad, pero también incrementa la fatiga de supervisión, ya que el desarrollador debe seguir controlando la intención y la calidad, lo que sacude la satisfacción y la sostenibilidad
  • Los modelos generan código plausible rápidamente, pero pueden perder la intención coherente de cambios complejos, por lo que el humano se convierte en una compuerta de calidad que revisa y corrige un volumen mayor de resultados
  • Aunque se disparan las tareas que se pueden iniciar, la cantidad de trabajo que puede terminarse con cuidado sigue limitada por el cerebro y la atención humanos; las pequeñas recompensas de programar disminuyen y la carga cognitiva de revisar aumenta
  • En áreas que se entienden en profundidad, es posible guiar eficazmente a los LLM, pero en áreas donde la especialización es superficial tienden más a lo plausible que a lo correcto, por lo que el gusto y el criterio arquitectónico se vuelven más importantes
  • La ingeniería de software no desaparece, sino que se reduce y se reconfigura; el recurso escaso no es escribir código en sí, sino la atención humana, el juicio de ingeniería y la capacidad de mantener una visión coherente del sistema

Programación con LLM: útil, pero inestable

  • La programación con LLM es realmente útil y, al mismo tiempo, inestable; si se ignora esa inestabilidad, los desarrolladores pueden terminar quemados
  • El equipo de Pydantic también atraviesa la misma confusión mientras construye herramientas de validación de datos, creación de agentes de IA y observabilidad en producción
  • La cuestión central no es si la IA reemplaza a los programadores, sino cómo cambió la experiencia actual de desarrollo y con qué se puede mejorar

La sensación de construir a mano

  • La programación ha ofrecido una sensación de creación: construir algo solo con lógica y manipular directamente capas profundas de abstracción
  • En la experiencia de aprender ingeniería de software por prueba y error, en lugar de una formación formal en ciencias de la computación, los principios de arquitectura y calidad de código se parecen más a cicatrices acumuladas que a reglas de manual
  • Las herramientas low-code/no-code de la década de 2010 y productos como Dreamweaver también prometían crear cosas sin código, pero generaban spaghetti code por dentro y no cumplieron del todo las expectativas
  • Las herramientas de IA actuales, a diferencia del pasado, han reducido de forma significativa la brecha entre promesa y realidad, y justamente por eso se sienten más inquietantes

La experiencia real de que “el código se escribe solo”

  • El código, hasta cierto punto, se escribe solo, pero la experiencia humana de revisarlo, dirigirlo y corregir el rumbo puede empeorar
  • Douwe, mantenedor de Pydantic AI, tenía que revisar cada mañana unos 30 PR creados durante la noche por la IA de otras personas y decidir de inmediato sobre cada uno
    • La tentación de delegar también la revisión en la IA es grande, pero si se hace eso queda la pregunta de qué hace el humano
  • Incluso después de pasar casi dos días escribiendo y aclarando iterativamente el plan que ejecutaría un LLM, el modelo puede mover hooks de React a archivos de stories de Storybook o leer un plan incorrecto y crear componentes que no existen
  • Estos fallos se parecen menos a una simple falta de capacidad y más a una falta de coherencia
    • El modelo es lo bastante inteligente como para generar código plausible, pero puede no mantener una única intención a lo largo de un cambio complejo
  • El humano debe conservar la intención en la cabeza mientras juzga continuamente grandes volúmenes de resultados “mayormente correctos”, y en ese proceso aparece una nueva forma de fatiga de supervisión
  • También disminuye la recompensa de construir funciones con personas reales en open source y ayudarlas a mejorar sus capacidades
    • Cuando el trabajo entra en la caja negra de la IA, no hay nadie aprendiendo del otro lado, así que desaparece la satisfacción de colaborar

La trampa de intensificar el trabajo

  • El estudio de Berkeley Haas presentado por Simon Willison sostiene que el uso de IA, más que reducir la carga laboral, aumenta la intensidad del trabajo
    • Al final del día persiste la presión de escribir un prompt más o terminar una función más
    • La sensación de que el plan está casi listo puede llevar a seguir escribiendo prompts hasta cerca de las 2 de la madrugada
  • Marcelo, de Pydantic, bromea diciendo que cuando una sesión de Claude Code se detiene, hay que abrir cinco sesiones
    • La idea es que, si estás ocupado dando feedback a otras sesiones, ni siquiera te das cuenta de que una se detuvo
  • El trabajo en paralelo aumenta mucho la cantidad de cosas que se pueden iniciar, pero no cambia la cantidad de cosas que se pueden terminar con cuidado
    • Para completar el trabajo se necesita un recurso que no se puede paralelizar: el cerebro humano

La avería de la función de recompensa humana

  • Así como la función de recompensa en machine learning define buenos resultados para un agente, la programación manual también tenía pequeñas recompensas: resolver problemas, entender lógica compleja, lograr que compile y sentir control
  • La programación asistida por LLM automatiza las tareas que generaban esas recompensas dopaminérgicas y llena su lugar con la carga cognitiva de revisar y supervisar
    • Las partes satisfactorias se reducen
    • Las partes desgastantes aumentan
    • Todavía no existe una nueva recompensa que llene el vacío
  • Que la productividad aumente mientras la satisfacción cae no es una falla personal, sino una avería del feedback loop, y debe tratarse como un problema de ingeniería aparte

Aislamiento y recompensa variable

  • Programar con LLM puede convertirse en una actividad muy solitaria, en la que humano y máquina repiten prompts, correcciones y revisiones
  • Los momentos de preguntarle a un colega, explicar juntos un problema y compartir pequeñas alegrías al resolverlo se reemplazan por otro prompt
  • En equipos con una cultura colaborativa débil, la comunicación entre personas se retrae aún más y se vuelve difícil confirmar que otros también están teniendo problemas
  • El hecho de que los resultados a veces sean excelentes y otras veces basura, sin poder saberlo de antemano, crea una estructura de recompensa variable similar a una Skinner Box
  • Cuando hace falta, también se puede escribir código directamente, pero el trabajo asistido por LLM y el trabajo manual requieren modos de pensamiento muy distintos, por lo que cambiar entre ambos resulta incómodo
    • Permitirse alternar entre los dos modos requiere madurez y confianza

Similitudes con la transición al diseño responsivo

  • Alrededor de 2009, cuando la web pasó de layouts de ancho fijo en píxeles al diseño responsivo fluido, los diseñadores también experimentaron una pérdida de control
  • Para quienes habían construido su identidad y su expertise sobre layouts precisos y grids perfectos, la idea de que el diseño fluyera según anchos de pantalla y dispositivos arbitrarios fue un cambio fundamental
  • Los diseñadores que se adaptaron a la transición no abandonaron sus habilidades previas, sino que las reconfiguraron
    • El sentido de proporción y la comprensión de la jerarquía siguieron siendo importantes
    • La obsesión por el control píxel a píxel perdió importancia
    • Diseñar para sistemas, adaptabilidad e incertidumbre se volvió más importante
  • La transición actual hacia la IA es mucho más rápida que la del diseño responsivo y también tiene otros intereses en juego
    • El cambio del diseño responsivo tomó años, pero el cambio actual avanza en cuestión de meses
    • En aquel entonces también hubo agencias que perdieron clientes y diseñadores que perdieron trabajo, pero no vino acompañado de la misma ansiedad existencial de hoy
  • Aun así, el patrón de que las habilidades evolucionan en lugar de desaparecer y de que las capacidades centrales se vuelven más importantes también aplica al coding basado en LLM
  • Que los ingenieros no escriban todo el código directamente no reduce su valor, pero al convertirse en compuertas de calidad de una cantidad mucho mayor de resultados, necesitan todavía más capacidad para distinguir los buenos resultados

La expertise que sobrevive y las nuevas formas de trabajo

  • En un entorno donde cualquiera puede crear UI plausibles y código que compila, el gusto y los matices, el criterio arquitectónico maduro y las decisiones no convencionales basadas en experiencia real se convierten en diferenciadores
  • Cuanto más profundamente se entienden el código, las decisiones y los trade-offs de un área, más exitosamente se puede guiar a un LLM
  • Cuanto más superficial es la expertise en un área, más lejos queda el resultado de estar listo para producción y más se acerca a algo impresionantemente plausible, pero no necesariamente correcto
    • El modelo rellena los huecos con confianza sin saber lo que no sabe, una forma de fallo que también aparece en los humanos
  • Para planes complejos se puede usar un pre-mortem
    • Pedirle a una nueva sesión de LLM que asuma que el plan fracasó desastrosamente y diagnostique las causas
    • Esto ayuda a encontrar vacíos en la especificación que se le escaparon a alguien que pasó dos días mirando los detalles
  • Un ingeniero de Pydantic desarrolló una herramienta que extrae reglas a partir de miles de comentarios de revisiones de código pasadas y las convierte en instrucciones iniciales para un archivo AGENTS.md
    • Es una destilación de expertise: transformar el juicio de ingeniería acumulado tácitamente durante años en instrucciones que un LLM pueda seguir
  • Quienes se adaptan al cambio tienen criterios sólidos adquiridos en la práctica y distinguen entre principios que siguen siendo válidos y hábitos nacidos de antiguas restricciones de ancho de banda
  • Están dispuestos a cambiar sus flujos de trabajo sin abandonar sus estándares

El recurso escaso revelado dentro del loop

  • La ola actual de IA no acabará con la profesión de ingeniería de software, pero puede provocar una reducción severa y una reconfiguración fundamental de la industria
  • Son legítimos los miedos a quedar obsoleto, a que las capacidades se degraden y a quedarse atrás si no se avanza lo suficientemente rápido
    • La última preocupación a veces se exagera, pero no carece por completo de fundamento
  • El verdadero cuello de botella no era el código, sino la atención humana, el juicio de ingeniería y la capacidad de mantener una visión coherente del sistema
  • Antes este cuello de botella no se veía con claridad porque escribir código parecía la parte difícil, pero al automatizarse el proceso de escritura queda más claro que la capacidad humana es el verdadero recurso escaso
  • Los desarrolladores pueden ser más productivos y, al mismo tiempo, menos felices y más inestables; los equipos que construyen herramientas también atraviesan el mismo problema y ajustan la función de recompensa en tiempo real
  • El código y la forma de desarrollar están cambiando, pero el humano sigue dentro del loop, y el estado central actual es la fatiga del participante humano

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Comentarios de Hacker News

  • Cuanto más difícil era programar a mano, mayores eran las pequeñas recompensas como resolver problemas, entender la lógica, lograr que compilara y sentir control. En cambio, la programación con agentes sigue exigiendo una supervisión parecida sin importar el tamaño de la función, así que al principio emociona como si uno se subiera a una ola de productividad, pero las partes satisfactorias disminuyen y la carga cognitiva de revisar aumenta, por lo que uno se agota rápido

    • Más que perder el trabajo, me da miedo que pronto termine odiando el trabajo en sí. Las tareas en las que dar instrucciones a un LLM no ahorra mucho tiempo las hago yo mismo, y vuelvo a pulir la estructura de la salida para que sea más fácil de entender para una persona, manteniendo así la sensación de control
    • Mi motivación no está tanto en cómo se hizo el código, sino en si más gente puede usar útilmente el producto creado. Siempre he puesto primero al usuario y, si hace falta, he tomado atajos; incluso usando LLM se puede equilibrar código mantenible con velocidad de lanzamiento
    • El desarrollo podría cambiar de una profesión basada en conocimiento a algo más parecido a trabajo de fábrica con salarios bajos. Guiar a un LLM requiere mucho menos conocimiento y experiencia que escribir directamente, y en LinkedIn ya están contratando como ingenieros de IA a personas con casi nada de experiencia o apenas nivel junior
    • Siento dopamina al crear bucles donde la IA prueba por sí sola sus propias salidas. Cuanto más era una automatización tipo Rube Goldberg, como hacer que Codex controlara de forma remota un adaptador de teclado network-USB-C, un Fingerbot y hasta una webcam para lograr que funcionara la hibernación en cierta laptop y kernel de Linux, más satisfacción me daba
    • En proyectos personales, como las funciones se crean más fácilmente y los resultados son más refinados y consistentes, la satisfacción incluso aumenta. Si me concentro un mes en un proyecto puedo obtener resultados bastante buenos, y como reescribir y reorganizar la estructura se volvió barato, realmente puedo explorar con mucha más amplitud el espacio de diseño. Aun así, también hay mucha frustración: la mitad es problema mío al dar contexto y la otra mitad son límites inherentes del modelo

  • Estoy usando Claude con gusto tanto en el trabajo como en proyectos personales, y la clave es evitar la tentación del agente y tratarlo como generador de código. Abro una sola sesión, afino bien el plan, observo la ejecución paso a paso y, al terminar cada etapa, reviso y corrijo el rumbo; así también al final mantengo una buena idea del estado del código
    Para usarlo casi como one-shot, en la fase de planificación hay que concretar no solo la arquitectura sino también el código real que determinará las decisiones principales. Como el costo del refactor nunca había sido tan bajo, cualquier parte difícil de entender la corrijo de inmediato con el LLM, pero un solo LLM debe hacer una sola cosa a la vez y uno debe seguir participando en el proceso

    • Después de trabajar varios meses con Claude, aprendí un flujo en el que al principio se discuten suficientemente los detalles y, si hace falta, hasta se arma el esqueleto antes de ponerlo a ejecutar; lo resumí en https://github.com/ctomkow/claude/blob/main/README.md. Estoy refactorizando con éxito código legacy que había ido postergando hacia una nueva arquitectura
      Darle control total a Claude inevitablemente genera confusión y obstáculos que terminan agotando a la gente. Si programas tú mismo cuando quieres y se lo pasas a Claude cuando estás cansado, también puedes mantener la sensación de control sobre la base de código
    • Pego solo los fragmentos de código necesarios en una conversación completamente separada del editor, discuto restricciones e ideas y, si el resultado me convence, lo paso al editor para pulir más los nombres y la implementación. Las tareas claras o divertidas las hago yo mismo, y también hay que involucrarse en las decisiones de arquitectura para sentir conexión con el proyecto y entenderlo a fondo
    • El vibe coding, incluso usando varios bucles de agentes, agota más que un enfoque de herramienta auxiliar donde uno observa de cerca la salida
    • Aunque se trabaje de forma incremental, cuando otra persona revisa tiene que mirar el resultado completo de una sola vez y con ojos nuevos, así que la carga de revisión no disminuye
    • El flujo de trabajo puede alternar entre dos cosas como máximo; más que eso y los cambios de contexto dejan la cabeza completamente agotada

  • Al revisar código de colegas o subordinados, la mayor parte de mi energía mental se va no solo en la validez técnica del feedback, sino también en el ego, diferencias de visión arquitectónica, tono cortés, carga extra de trabajo y dinámica del equipo. En cambio, con un LLM no hace falta preocuparse por el impacto emocional, así que revisar y corregir el rumbo es mucho más fácil

    • Si sé que un colega va a volver a pasar mi feedback a una IA, termino escribiendo para la IA más que para la persona, y entrego una lista de cambios mucho más corta y directa
    • Como tech lead, siempre he lidiado con la resistencia de “con esto ya es suficiente” en cada PR, pero con un LLM puedo pedir cómodamente que lo rehaga de la forma correcta sin resistencia

  • En el trabajo empezamos a llamarlo Human on the hook en lugar de human in the loop. Expresa mejor una estructura donde, si sale bien, el humano no recibe crédito, pero si sale mal sí carga con la responsabilidad; es decir, el humano solo importa cuando aparece un problema

  • Escribir código en sí nunca fue para mí la parte difícil. Tecleo rápido, uso edición modal de Vim, comandos Unix, scripts y atajos, Git, refactors del IDE, y aprendí Java; cuando sé qué quiero construir, trabajo a la velocidad del pensamiento
    El momento en que me detengo no es por tecleo ni por sintaxis, sino al pensar en la forma del código y en el cambio correcto; cuando se complica, creo mejores abstracciones, herramientas del IDE o pipelines de Unix incluyendo sed. Por eso, el cuello de botella no era escribir código sino pensar y juzgar
    Una razón por la que la programación con IA puede sentirse como un gran salto es que quizá hay más desarrolladores de lo esperado que nunca se toparon con herramientas excelentes o no llegaron a dominarlas. Si hoy tuviera 20 años, probablemente habría dedicado menos tiempo a aprender estas técnicas, pero el momento en que la ingeniería de software se volvió fascinante para mí fue cuando entendí que nada de esto era magia

    • La frase “la IA parece buena en cosas en las que uno mismo no es bueno” encaja muy bien. Si uno tiene poca soltura programando, la salida de la IA puede parecer rápida y excelente, pero para un desarrollador experimentado, si sumas dar instrucciones, esperar, persuadir, corregir y refactorizar, puede que no sea más rápido que hacerlo uno mismo
      Así como yo soy malo dibujando y por eso las imágenes de IA me parecen impresionantes, la programación con IA puede evaluarse con la misma lógica

  • El cansancio que siente mucha gente viene de una pérdida de control producida por la combinación de más impulso y más confusión. Los LLM están en algún punto entre un genio y un bebé, así que observar desde el asiento trasero resulta emocionante pero también aterrador
    Después de correr rápido durante un tiempo, quizá uno descubra que caminar tampoco estaba mal y que, de hecho, había más posibilidades de llegar al destino que quería

  • Programar con LLM se siente como jalar la palanca de una tragamonedas: repetir el ritual esperando que ahora sí funcione. Los errores en la programación tradicional tienen causas consistentes, y se diseña para entender esas causas y eliminarlas de forma permanente cuando sea posible. Un desarrollador con experiencia no hace intentos al azar y, si tiene éxito, no lo descarta como algo cuyo motivo desconoce
    Si ya estabas agotado por lidiar con múltiples partes interesadas que ni siquiera logran ponerse de acuerdo sobre qué es el sistema, quizá ya sabías desde hace tiempo que la atención humana y el criterio de ingeniería eran el verdadero cuello de botella

    • Cuando estaba aprendiendo a programar y hacía apps web, me quedaba pegado a la computadora hasta tarde, adivinando a ciegas y probando con un “¿y si hago esto?”. A medida que mejoré y empecé a usar lenguajes tipados, compiladores y LSP, llegué a entender qué iba a funcionar, y pude entrar en un estado de flujo satisfactorio en lugar de esa adivinanza adictiva
      Programar con Claude se siente como volver a esa etapa de adivinar, así que no lo quiero. Aun así, en áreas donde ya había mucha prueba y error a ciegas, como el trabajo tipo DevOps de conectar APIs complejas y varios componentes, la conversación con LLM es donde más sirve
    • Ahora, en vez de llegar a acuerdos, las partes interesadas usan LLM para crear planes a medio cocinar y objetivos trimestrales; luego le dejan al LLM el diseño, las historias, los detalles técnicos, la implementación y hasta la revisión de código. En todo el proceso, desaparecen el pensamiento crítico y la verificación, y solo se acumulan documentos de diseño y código con un propósito poco claro que ya ni se pueden seguir
      Los planes pueden cambiar en cualquier momento y también es mucho más probable que, por impulso, se reescriba todo por completo

  • Coincido con la idea central del texto, pero por todas partes se nota el estilo característico de Claude, y leer un texto que alguien escribió con IA cansa más

    • Más que haberlo escrito directamente una IA, es probable que haya pasado por edición y revisión para ajustarlo a un estilo corporativo. El propio LLM también fue entrenado con ese estilo
    • Casi todo fue escrito por IA, pero hubo mucha más intervención humana que en un texto típico de IA, así que no molesta tanto como de costumbre
    • Por las muletillas de estilo, como repetir “It’s not” y usar guiones, se nota que fue escrito por IA
    • Si no se tomaron la molestia de escribirlo ellos mismos, yo tampoco quiero tomarme la molestia de leerlo

  • Me recordó al texto de 2021 The Animal is Tired: https://www.robinhobb.com/blog/archives/2021-05

    • Como el sitio original bloquea IP, puede verse en este espejo menos restrictivo https://archive.is/RWxXP. Sentir el propio deterioro puede ser la tristeza más grande, y le llega a todo el mundo
      Aunque uno hubiera cuidado más su cuerpo, quizá habría llegado al mismo punto de todos modos y se habría perdido recuerdos valiosos. Hay que cuidar el cuerpo, pero no tratarlo como una poción de videojuego que nunca usas por si la necesitas en la siguiente pelea. Cada parte de nuestro cuerpo solo puede sacrificarse una vez por un propósito mayor, o no sacrificarse en absoluto
      Incluso pensar en esto todavía me hace llorar, de lo emocionalmente frágil que sigo

  • La difusión de la investigación de Berkeley Haas sobre cómo usar IA aumenta la intensidad del trabajo es llamativa, pero más de cinco meses después de que salieran el artículo de HBR https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... y el material promocional https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo..., sigue sin poder encontrarse el paper real ni una versión preliminar
    Por ahora, lo único que se sabe es que se basa en unas 40 entrevistas cualitativas realizadas en una sola empresa de una sola industria, así que es difícil evaluar la confiabilidad de los resultados sin revisar la metodología del estudio