La trampa de programar con IA

• Los agentes de codificación con IA están aumentando de forma drástica la velocidad de escritura de código, pero la parte más importante del desarrollo sigue siendo la comprensión y la resolución de problemas
• Con un LLM se puede generar código rápidamente, pero por la falta de entendimiento del contexto completo, se requiere más tiempo para el posprocesamiento y la comprensión
• Esto genera una brecha entre las expectativas de productividad y la eficiencia real, y provoca que los desarrolladores dediquen tiempo a tareas repetitivas y pesadas como pruebas, refactorización y documentación, en lugar del trabajo creativo que desean hacer
• Como en el pasado con el ‘dilema del tech lead’, si por resultados de corto plazo se concentran las tareas complejas en la IA o en los seniors, se puede provocar una caída de la capacidad del equipo a largo plazo y una futura crisis
• Hay que entender al LLM como un ingeniero junior muy potente y aplicar procesos de desarrollo probados a la colaboración con IA para construir una estructura de entrega de software sostenible

---

Reconocer el problema: lo que importa más que programar en sí

• El desarrollo de software es un trabajo centrado en la resolución de problemas
• Programar de verdad corresponde solo a la parte final de todo el pensamiento y análisis del desarrollador
• Además del código, los desarrolladores realizan muchas otras tareas: entender el dominio, desglosar requisitos, abstraer, considerar efectos secundarios, probar de forma gradual y corregir bugs
• Flujo de desarrollo tradicional: pensar lo suficiente antes de escribir código
• En la era de la programación con IA: se pasa al patrón de código primero, comprensión después

El cambio en la programación con IA: un paradigma donde el código se genera primero

• Los agentes de codificación con IA como Claude Code generan código rápido, pero no logran comprender por completo el contexto del sistema entero
• El proceso humano de revisión, pruebas e integración sigue siendo indispensable, y entender a posteriori el código escrito por la IA consume mucho tiempo
• El marketing enfatiza la mejora en la velocidad de programación, pero la mejora real en la productividad para entregar software funcional es mínima
• Los desarrolladores invierten más tiempo en tareas repetitivas y difíciles como pruebas, eliminación de duplicados, documentación y gestión de infraestructura del resultado generado por la IA
• Se reduce el placer real de programar y aumenta la experiencia de trabajo repetitivo

El viejo dilema del líder técnico

• Cuando un ingeniero asume el rol de tech lead, carga con la responsabilidad de la entrega técnica del equipo
• Cuando la experiencia del equipo se concentra en una sola persona, se produce un desequilibrio de productividad
• Surge un conflicto entre dos estrategias: distribución equitativa (priorizar el crecimiento del equipo) y concentración de trabajo (centrarse en desarrollar más rápido)
  • Concentrar el trabajo da beneficios a corto plazo, pero provoca riesgos de largo plazo para el equipo por la concentración de experiencia, como falta de respaldo, burnout y dificultad para dar soporte
• Para una cultura de equipo sana, hace falta una manera de equilibrar crecimiento y eficiencia

La clave del buen liderazgo: equilibrio entre proceso y crecimiento

• Es necesario aplicar distintos principios de desarrollo y frameworks para que todo el equipo adopte el know-how de los ingenieros con más experiencia
• Ejemplos: Extreme Programming, code review, despliegue gradual, diseño modular, desarrollo guiado por pruebas, pair programming, documentación e integración continua
• Objetivo final: minimizar el retrabajo, maximizar la colaboración y fomentar el crecimiento individual

Colaboración con agentes de IA: un nuevo rol de líder de equipo

• Los agentes de codificación modernos basados en LLM se parecen a un desarrollador junior increíblemente rápido
• A diferencia de un junior tradicional, el LLM tiene dos rasgos claros: no aprende y no tiene límite de velocidad
• La IA sigue enfocándose en aumentar la velocidad más que en mejorar la calidad, y carece de comprensión humana del contexto y del dominio
• Dos patrones de colaboración:
  • Ingeniería basada en IA: busca un trabajo en equipo más lento, pero eficiente y sostenible
  • Vibe coding: se enfoca en obtener resultados rápidos, pero acumula cada vez más un caos irrecuperable
• Se parece al punto ciego tradicional del crecimiento de código en Silicon Valley: tras las ganancias de corto plazo, se llega a un muro de límites de crecimiento

Cómo sobrevivir en la trampa de programar con IA: métodos prácticos

• El LLM no conoce su propia situación y produce código indiscriminadamente
• Los ingenieros deben dar a la IA una estructura, estándares y procesos claros para convertir una salida cruda en un servicio real
• Hace falta un nuevo playbook que aplique de cerca las best practices del ciclo de desarrollo tradicional al entorno de colaboración con IA
• Formas clave de usar IA por etapa:
  • Definición de especificaciones: análisis de edge cases y enfoque en el alcance objetivo
  • Documentación: asegurar guías y evidencia reutilizables
  • Diseño modular: mejorar la comprensión al limitar el contexto
  • Desarrollo guiado por pruebas: generar casos de prueba antes de implementar y evitar regresiones
  • Estándares de código: mantener estilo y calidad
  • Monitoreo: análisis automático de logs y obtención de insights

Conclusión

• La entrega de software no se logra solo escribiendo código; es indispensable establecer una estructura de colaboración eficiente entre IA y humanos
• Si se considera al LLM como un desarrollador junior ultrarrápido y se aplican procesos de desarrollo probados, será posible entregar software de alta calidad y escalable

[GN⁺]

Opinión de Hacker News

• Me gustaría ver argumentos anti-AI que no se basen simplemente en la idea de que “la tecnología vuelve floja a la gente”. Quien haya intentado seriamente producir código con LLM siente que el ciclo de planificar-estructurar-probar-retrospectiva sigue siendo muy importante. Si lo pones a correr sin cuidado, se rompe enseguida. Si aplicas bien ese ciclo, puedes dedicar mucho tiempo a probar el diseño de arquitectura y la experiencia del resultado, que es lo que me gusta. Como los LLM resuelven rápido las partes fáciles, al final lo que nos queda por hacer es lo menos interesante y menos agradecido. En las áreas donde la AI hace brillar la especialización, se nota con mucha claridad la diferencia de perspectiva entre quien disfruta el trabajo en sí y quien disfruta la experiencia de pensar. A quien le gusta pensar, la AI le permite concentrarse casi por completo en eso. En cambio, para quien disfruta escribir y manipular directamente, la AI más bien le quita la parte que le gusta

  • En cuanto a la generación de código con AI, creo que una crítica más importante que la idea de que la tecnología vuelve floja a la gente es que te quita la comprensión profunda del código generado por la AI. Lo esencial del trabajo de un ingeniero de software no es generar código, sino diseñar el sistema completo. Lo importante aquí es el modelo mental de cómo funciona el código y la especialización en el dominio; el código es un resultado derivado de ese modelo mental. En proyectos de cierta escala, es difícil conocer por completo un código si no eres quien lo escribió. Si no construyes ese modelo mental, también aparecen otros problemas. Los agentes de programación basados en LLM tienen límites en su razonamiento a nivel de sintaxis, así que muestran debilidades para escalar

  • Si doy mi opinión, uso de vez en cuando herramientas de AI como Cline, pero cada vez aumento más la proporción de código que escribo yo mismo. La razón es que en la mayoría de los casos solo sustituyes programar por escribir prompts. Si el tiempo de redactar el prompt y esperar el razonamiento es menor que el de programar con mis propias manos, uso AI, pero por lo general eso solo aplica cuando hay un cuello de botella de velocidad, como en un refactor. En la mayoría de las tareas, si lo hago yo tardo 10 minutos, y con AI tardo 8 minutos entre escribir el prompt y ejecutarlo. Si sale bien sin errores, me ahorré 2 minutos, pero si hay que corregir o volver a promptar, termina tomando 10 a 12 minutos y además ya gasté créditos de AI, así que es lo peor. Haciendo esas cuentas, llegué a la conclusión de que, considerando tanto la calidad del código como el tiempo requerido, lo manual es más seguro

  • Sobre la idea de que la tecnología vuelve descuidada a la gente, en general muchas veces la tecnología hace que la gente sea más cuidadosa. El problema es que esta tecnología de AI tiene muchas posibilidades de inducir al descuido en el usuario. A mí no me interesa tanto la parte divertida de programar; prefiero el diseño, la arquitectura en sí. Si pudiera reflejar la intención directamente en el código, usaría ese método. Pero una interfaz de chatbot transmite la intención de forma indirecta e imperfecta, así que cuando la uso para construir código de alto nivel, el modelo que tengo en la cabeza y mi comprensión del código real se distancian rápidamente, dejando una base inestable. Podría revisar cuidadosamente línea por línea, pero eso va en contra del propósito de la herramienta. La programación con AI, por esa sensación de ser “10 veces más rápida”, fomenta la separación entre la implementación detallada y la comprensión macro. De hecho, pensar menos en la parte estructural es uno de los beneficios principales con los que se promociona la programación con AI, pero esa brecha de entendimiento luego causa problemas. Una buena automatización es confiable y predecible, así que basta con entender las invariantes de alto nivel, pero el código de chatbot no da esas garantías y al final crea una estructura en la que hay que verificarlo todo manualmente. Aquí, la seguridad y la confiabilidad se sienten más difíciles, no menos

  • Veo tan seguido la lógica de “concéntrate en la parte de pensar” que ya me parece trillada. El problema es que me pregunto si alguien que no ha trabajado directamente durante años en la práctica puede hacer una actividad profunda solo pensando. Al final, sin la experiencia de hacerlo uno mismo, incluso el pensamiento corre el riesgo de volverse cada vez más superficial

  • Mi postura es que depurar es más difícil que escribir, así que prefiero escribir yo mismo antes que depurar código que no escribí

• Cada vez que leo este tipo de discusiones, siempre pienso lo mismo: me pregunto si el autor estará usando las mismas herramientas que yo. Con Claude Code puedo generar casi de todo, desde boilerplate simple hasta algoritmos complejos, incluso dentro de codebases enormes y muy confusos. Claro, no acierta al 100%, pero se queda muy cerca. Además, a menudo propone algoritmos que a mí no se me habrían ocurrido. Estas herramientas me ahorran por lo menos 10 veces mi tiempo

• El artículo está bien, pero veo dos premisas engañosas. Primero, incluso cuando un desarrollador experimentado usa un LLM, sigue siendo indispensable una exploración suficiente, reflexión previa y diseño. De hecho, para aprovechar bien un LLM hay que pensar más que de costumbre, comparar varias alternativas de diseño y dibujar la estructura completa. Antes no documentaba ese proceso, pero ahora sí lo dejo en documentos de diseño. Segundo, está la afirmación de que un LLM es como un desarrollador junior que no crece, pero ambos son completamente distintos. Un desarrollador junior humano es una persona y un LLM es una herramienta. Lo importante, dicen, es que al trabajar con un junior se acumula valor con el tiempo y con un LLM no; pero eso tampoco es correcto. Aunque el LLM no aprenda, yo sí aprendo a guiarlo con mucha más eficiencia y a usarlo mejor. Estamos en una etapa temprana de aplicar bien los LLM a los productos, así que naturalmente se ve un valor de crecimiento compuesto

  • Coincido con “aunque el LLM no aprenda, yo sí aprendo”, pero aun así quisiera que el LLM de verdad aprendiera de la interacción con el usuario. Lo que quiero es poder guardar/cargar el contenido de una sesión en un archivo para que el LLM entienda sin omisiones todo el contexto aprendido antes. Algunas UI de frontend permiten guardar y restaurar sesiones, pero lo importante es que a) ese “reaprendizaje” no afecte la context window actual del LLM —ojalá ese concepto desapareciera por completo—, y b) que sea un método sin pérdida absoluta. Ya existen enfoques como resumir y continuar o RAG, pero todos tienen limitaciones fundamentales, como pérdida de información o que la restauración solo sea posible si la activa la interacción actual. Por ejemplo, si ayer le expliqué al LLM una función, guardé la sesión y hoy la restauro, me gustaría que aunque le haga una pregunta sin ninguna relación, el LLM responda considerando también todo ese contexto anterior. Y cuando quiera un clean slate, debería poder hacerlo de manera explícita

  • Es cierto. En la productividad total del software, el tiempo de pensar pesa mucho más que el tiempo real de escribir código, así que aunque el LLM acelere la parte de codificar, eso no provoca un cambio dramático en la productividad total ni en la demanda de personal

  • Empezar con un prompt de DO NOT WRITE ANY CODE YET también es mi base. Es una forma de entender primero qué intenta hacer el LLM y asegurar mi control. Me divierte más el diseño en sí —lógica, resolución de problemas, integración de sistemas— que escribir código

  • Hay funciones como el modo Ask de Copilot o el modo Plan/Chat de GPT-5 Codex que permiten planificar sin modificar archivos de código. Probé Codex unos días y, si le das instrucciones suficientes, es excelente

  • Yo también prefiero en la mayoría de los casos pedirle al LLM primero un plan antes de una ejecución concreta, algo como “primero dime el plan”

• Este artículo cita únicamente material de marketing de Microsoft para afirmar una mejora del 10% en productividad, pero en un estudio de Harvard en realidad se registró una caída del 10% en productividad. Preferiría un texto que primero citara resultados de investigaciones independientes, no la promoción de una empresa específica

• Uno de los puntos clave que este artículo no termina de transmitir es algo que mencionó Casey Muratori: “si programas con una mentalidad centrada en aprender, la AI más bien pierde sentido”. Personalmente, siento que los generadores de código con AI solo sirven para código desechable, de una sola vez. En áreas donde quiero aprender en serio, sentí que dejar la generación de código en manos de la AI no maximiza el aprendizaje. Seguro hay gente para la que la “ingeniería impulsada por AI” sí es significativa, pero al menos para mí, escribir directamente los bloques de código con mis manos es más divertido y al final siento que también termino mejor el resultado. Video relacionado, dura 5 minutos

  • La lógica de “el estado que maximiza el aprendizaje es no generar código con AI en absoluto” me parece demasiado extrema. Aunque sea importante intentar hacerlo por cuenta propia para aprender, se siente como una afirmación demasiado fuerte, casi equivalente a decir que no debes comunicarte con otros ni pedir ayuda en absoluto

• Desde que uso Claude Code, paso mucho más tiempo pensando. Antes no me ocurría describir una función que quería en 400 a 600 palabras, pero ahora organizo mucha más información con detenimiento. Gracias a ese proceso salen resultados más rápidos y mejores, pero al mismo tiempo mi comprensión del código sí es algo menor que antes. Aun así, no puedo estar de acuerdo con la idea de que al usar Claude Code un desarrollador con experiencia piensa menos. Quizá mucha gente usa agentes de manera ineficiente, por ejemplo limitándose casi solo a escribir prompts, pero no creo que sea culpa del agente

• Viendo estas discusiones, pienso que todavía estamos en una fase intermedia ambigua. Para el próximo año, da la impresión de que debates como los de hoy serán tratados como “pensarlo demasiado”. Se parece a la época en que, antes y después de la masificación de internet, había muchas dudas como “es una moda pasajera” o “es una mala inversión”

• Lo que estos artículos suelen pasar por alto es lo siguiente

  1. No toda programación es igual. La otra persona puede estar hablando de un sistema de producción y yo de un experimento simple
  2. Cada quien usa los agentes de forma distinta
  3. El tiempo de un gran desarrollador también cuesta
     Ojalá hubiera un artículo que solo organizara de forma sistemática las ventajas, desventajas y trade-offs de la asistencia de código con AI. Hace falta discutirlo sin juicios morales de valor (bueno/malo). Admito que es especialmente difícil abordarlo con frialdad cuando la “habilidad para programar” forma parte de tu identidad
  • El texto principal sí menciona una vez tu punto 1 (la diversidad de contextos de programación)

• Todos los días me animo a mí mismo diciéndome “solo aguanta 30 años más y jubílate”. Llevo 10 años en machine learning, estoy cansado de estar frente a la computadora y cansado del trabajo. Solo quiero tirarme en el pasto

  • Parece que necesitas un descanso, hasta un sabático; te lo recomendaría

• La gráfica de “pensar y programar vs pensar y corregir” es interesante. Últimamente, usando Codex, sí esperaba que la AI terminara corrigiendo mucho de mi código. En la práctica, cuando la causa del problema no tiene absolutamente nada que ver con el código, se pierde una cantidad enorme de tiempo. Hace poco me pasé mucho rato revisando solo el código por un problema de autenticación, y al final resultó que la causa era una falla en la configuración de ipv6 de la VM

[shakespeares]

Me identifico con esto. Cuando he hecho programación con IA, hay demasiado trabajo de posprocesamiento, así que es muy difícil incorporarlo al negocio real y darle mantenimiento.
Incluso avanzando con el enfoque de que estamos desarrollando juntos y tratando de intercambiar la mayor cantidad posible de ida y vuelta, como parte del código no fue escrita directamente por uno mismo, muchas veces termina desvaneciéndose de la cabeza.
Creo que sin duda es necesario poner límites.