Programar con LLM se siente más rápido — y más agotador

Programar con LLM ya es lo suficientemente útil como para importar — y lo bastante inquietante como para agotar a la gente. En un nuevo ensayo, Pydantic sostiene que los desarrolladores están siendo empujados a un papel extraño: menos constructores manos a la obra y más supervisores agotados de máquinas que pueden generar mucho código plausible pero que todavía no captan el objetivo.

La autora Laura Summers dice que esa tensión es fácil de pasar por alto si la industria se concentra solo en las ganancias de productividad. En Pydantic, que crea herramientas para validación de datos, agentes de IA y observabilidad en producción, el equipo también está sintiendo la presión.

Recuerda a un colega, Douwe, que describía cómo se despierta cada mañana con treinta pull requests, cada una enviada durante la noche por el flujo de trabajo de IA de alguien, y tiene que emitir juicios rápidos sobre todas ellas. La tentación obvia es dejar que la IA revise también el código generado por IA. Pero, como dijo Douwe:

¿en ese punto, qué sigo haciendo aquí?

Summers dice que la fatiga no se trata solo del volumen. Es el coste mental de mantener el diseño previsto en la cabeza mientras un modelo produce una salida “casi correcta” que aún necesita una revisión minuciosa. Describe haber pasado casi dos días completos escribiendo y afinando un plan para un LLM, solo para verlo sacar del plan equivocado o inventar componentes que no existían.

Recomendado

Google Pics llega a Workspace el 18 de agosto

Eso, argumenta, crea una nueva clase de agotamiento: la fatiga de la supervisión. Las partes gratificantes de programar —resolver el problema, entender la lógica, sentir que tienes el control— se automatizan en parte, mientras que las partes agotadoras se amplían.

Vincula eso con un aumento más amplio en la intensidad del trabajo, citando un estudio de Berkeley Haas destacado por Simon Willison. El patrón es familiar: un prompt más, un ajuste más, una característica más antes de desconectarse. Summers dice que recientemente se quedó despierta hasta casi las 2 a. m. porque sentía que estaba cerca de acertar con un plan.

El ensayo también señala un coste social. Trabajar con LLM puede convertir la programación en un ciclo inusualmente solitario, reemplazando las conversaciones con compañeros y las pequeñas victorias compartidas por otra ronda de prompts. Eso puede debilitar la colaboración, especialmente en equipos que no tienen ya una cultura de comunicación sólida.

Más adelante, Summers compara el cambio actual con la conmoción alrededor del diseño responsive hacia 2009, cuando diseñadores y desarrolladores frontend tuvieron que renunciar a los diseños de ancho fijo y píxel-perfectos por sistemas más fluidos.

Su argumento no es que la ingeniería de software esté desapareciendo. Es que el trabajo se está remodelando, y rápido. En un mundo donde más personas pueden producir código que compila, los factores diferenciadores pasan a ser el gusto, el juicio arquitectónico y la capacidad de distinguir cuándo algo simplemente parece correcto.

El equipo de Pydantic dice que de ese cambio están surgiendo algunas prácticas nuevas. Summers describe realizar pre-mortems con una sesión nueva de LLM para identificar por qué un plan podría fallar. También menciona a un ingeniero que creó una herramienta para extraer reglas de miles de comentarios de revisiones de código pasadas hacia un archivo AGENTS.md, convirtiendo años de juicio implícito en guías reutilizables.

Su conclusión es directa: el cuello de botella nunca fue solo escribir código. Siempre fue la atención humana y el juicio de ingeniería. Esos siguen siendo escasos — y, por ahora, cansados.