El papel de las capacidades del desarrollador en la codificación agéntica

• A medida que los asistentes de codificación agénticos se vuelven más capaces, las reacciones han sido muy diversas, y algunos incluso afirman que "en un año ya no se necesitarán desarrolladores"
• Otras personas plantean preocupaciones sobre la calidad del código generado por IA y sobre cómo preparar a los desarrolladores junior para este entorno cambiante
• En los últimos meses he usado asistentes de codificación agénticos como Cursor, Windsurf y Cline, y han sido muy efectivos para modificar bases de código existentes
• Me impresionó mucho la integración con el IDE: incluye ejecución de pruebas, corrección automática de errores, detección y corrección de errores de lint/compilación, búsqueda web e incluso vista previa en el navegador
• La experiencia de colaboración entre desarrollador e IA ha sido muy impactante y ha contribuido a resolver problemas e implementar funciones con rapidez

• Sin embargo, siguió siendo necesaria la intervención continua del desarrollador para corregir y dar dirección
• En muchos casos ni siquiera se llegó a hacer commit, y a la IA todavía le falta capacidad para escribir de forma autónoma código para tareas que no son triviales
• Por lo tanto, las habilidades y la experiencia del desarrollador siguen siendo importantes y deberán seguir entrenándose en el futuro

Momentos en los que el desarrollador tuvo que intervenir directamente

• Las herramientas de IA mostraron un rendimiento constantemente débil en ciertas áreas, y esto se confirmó repetidamente
• Parte de esto puede mitigarse parcialmente con prompts adicionales o reglas personalizadas, pero no es posible un control total
  • Los LLM a menudo no siguen con precisión las instrucciones del prompt
  • Cuanto más larga es una sesión de codificación, menos consistentes son los resultados
• Por eso, los casos que se presentan a continuación son problemas que pueden ocurrir con bastante facilidad independientemente del prompt o la configuración
• Los errores de la IA se clasifican en 3 categorías según su radio de impacto
  • a. Disminución de la velocidad de desarrollo y del tiempo hasta el commit
    • La IA termina ralentizando el trabajo
    • En algunos casos resulta menos eficiente que programar sin asistencia
  • b. Genera fricción en el flujo de trabajo del equipo
    • Provoca choques o problemas de colaboración dentro de una iteration
  • c. Deteriora la mantenibilidad del código a largo plazo
    • Al principio parece que no hay problema, pero luego aparecen dificultades al cambiar o ampliar el sistema
• Cuanto mayor es el radio de impacto, más largo es el bucle de retroalimentación para que el equipo detecte y corrija el problema

Radio de impacto: retraso en el tiempo hasta el commit

• Esta categoría reúne casos en los que la IA terminó estorbando en lugar de ayudar
• Como es la forma de fallo más evidente, no suele convertirse en un gran problema
  • En la mayoría de los casos, el desarrollador puede detectar y detener el problema antes del commit

• Código que no funciona

  • El código generado por la IA simplemente no funciona
  • El desarrollador necesita corregirlo directamente o cerrar la sesión de IA y resolver el problema manualmente
  • Un desarrollador con experiencia puede identificar rápido qué salió mal y actuar

• Diagnóstico incorrecto del problema

  • La IA identifica mal la causa del problema e intenta soluciones en una dirección equivocada
  • Basándose en experiencia previa, el desarrollador pudo reencaminar a la IA desde ese camino erróneo

    Ejemplo: confundió un error de build de Docker con un problema de configuración de arquitectura y modificó esa configuración
    La causa real era haber copiado node_modules compilado para una arquitectura incorrecta
    Como era un problema que ya había visto muchas veces antes, pudo reconocerlo y corregirlo rápidamente

Radio de impacto: flujo de trabajo del equipo dentro de una iteration

• Esta categoría cubre casos en los que, por falta de revisión o de intervención del desarrollador, surge fricción dentro del equipo durante el período de la iteration
• Gracias a experiencias previas en distintos equipos, el autor pudo detectar y ajustar estos problemas antes del commit
• Los desarrolladores nuevos también pueden aprender estas lecciones mediante prueba y error junto con la IA
• Pero si la IA acelera demasiado la velocidad de codificación, el equipo podría no ser capaz de absorber estos problemas

• Trabajo inicial excesivo

  • La IA tiende a intentar abarcar toda una funcionalidad de una sola vez, en lugar de implementarla de forma incremental
  • Si por eso se elige mal una tecnología o se entienden mal los requisitos, puede desperdiciarse mucho trabajo

    Ejemplo: al migrar el stack de frontend, intentó convertir todos los componentes de UI de una sola vez
    Debería haberse aplicado gradualmente empezando por un solo componente integrado con el backend

• Resolver a ciegas sin analizar la causa

  • La IA intenta solucionar solo el error visible sin analizar la causa raíz del problema
  • Luego, otro integrante del equipo que tome ese problema carga con la necesidad de volver a analizarlo sin contexto

    Ejemplo: ante un error de memoria durante el build de Docker, en vez de buscar la causa solo aumentó la configuración de memoria

• Complejiza el flujo de trabajo del desarrollador

  • La forma de compilar/ejecutar generada por la IA deteriora la experiencia de desarrollo
  • Si se hace commit de inmediato, también afecta negativamente el flujo de trabajo de los demás miembros del equipo

    Ejemplo: entrega comandos separados para ejecutar el frontend y el backend
    Ejemplo: omite la funcionalidad de hot reload
    Ejemplo: una configuración de build compleja confunde tanto a desarrolladores como a la IA
    Ejemplo: no detecta errores de Docker con antelación e intenta manejarlos solo al final del build

• Requisitos mal entendidos o incompletos

  • Si no se especifican claramente los requisitos funcionales, la IA puede malinterpretarlos e implementar la funcionalidad en una dirección equivocada
  • Lo ideal es corregirlo con intervención temprana, pero tanto con una IA autónoma como con un desarrollador poco reflexivo aumenta el costo de las correcciones posteriores
  • Estas implementaciones erróneas suelen descubrirse más adelante durante el avance de la historia, lo que genera mucho retrabajo y costos de comunicación

Radio de impacto: deterioro de la mantenibilidad a largo plazo

• Es el radio de impacto más sigiloso y peligroso
  • Al principio el código funciona sin problemas, pero después se vuelve difícil de cambiar y ampliar
• Muchas veces estos problemas solo se descubren semanas o meses después
• En esta área en particular fue donde más pesaron los más de 20 años de experiencia del autor como desarrollador

• Código de pruebas verboso y duplicado

  • La IA es buena generando pruebas, pero a menudo aparecen problemas como estos:
    • En vez de integrarse con las pruebas existentes, crea nuevas funciones de prueba
    • Agrega demasiadas assertions incluso en partes ya cubiertas
  • Un punto que los desarrolladores principiantes pueden malinterpretar: más pruebas ≠ mejores pruebas
  • Cuanta más duplicación haya, más difícil se vuelve el mantenimiento y mayor la posibilidad de fallas masivas en las pruebas cuando cambia el código
  • Se intentó mitigar esto con comandos personalizados, pero aun así sigue ocurriendo con frecuencia

• Falta de reutilización

  • El código escrito por la IA a menudo carece de modularidad, por lo que es difícil reutilizarlo

    Ejemplo: no reconoce componentes de UI ya existentes y los vuelve a implementar
    Ejemplo: abusa de estilos inline en lugar de usar clases de CSS

• Código excesivamente complejo o verboso

  • La IA a menudo genera más código del necesario, por lo que hay que eliminar manualmente partes innecesarias
  • Esto aumenta el costo de mantenimiento y eleva la probabilidad de errores al hacer cambios

    Ejemplo: al cambiar CSS, hay que borrar uno por uno muchos estilos duplicados
    Ejemplo: crea un web component innecesariamente complejo solo para mostrar datos JSON
    Ejemplo: durante una refactorización, no reconoce una cadena existente de inyección de dependencias,
    y complica el diseño al pasar de nuevo como otro parámetro un valor que ya estaba inyectado

    • Con una forma como value = service_a.get_value(); ServiceB(service_a, value=value)

Conclusión: ¿puede la IA escribir todo el código por nosotros?

• A juzgar por la experiencia hasta ahora, es poco realista que en un año la IA escriba de forma autónoma el 90% del código completo
• Aun así, como asistente para escribir código, en algunos equipos y bases de código sí podría alcanzar un 90% de apoyo
• De hecho, el autor recibe ayuda de IA en alrededor del 80% en un proyecto de complejidad media de unas 15K LOC

Cómo prevenir los errores de la IA

• Qué puede hacer cada desarrollador a nivel individual

  • Revisar siempre con cuidado el código generado por la IA
    • Casi nunca sale sin nada que corregir
  • Interrumpir de inmediato la sesión de IA si se vuelve confusa
    • Ajustar el prompt o directamente pasar al trabajo manual (también llamado "codificación artesanal")
  • Desconfiar de las soluciones "convincentes" que parecen haberse completado milagrosamente en poco tiempo
    • Puede haber costos ocultos de mantenimiento a largo plazo
  • Practicar programación en pareja
    • Cuatro ojos y dos cerebros ofrecen mejor criterio

• Estrategias de respuesta a nivel de equipo y organización

  • Aprovechar activamente las herramientas existentes de monitoreo de calidad de código
    • Ej.: Sonarqube, Codescene
    • Al usar herramientas de IA, hay que vigilar con más atención la duplicación de código, los code smells y otros problemas
  • Configurar hooks de pre-commit e integración de revisión de código en el IDE
    • Reforzar una estrategia shift-left para detectar problemas temprano en el desarrollo
  • Restablecer buenos hábitos de calidad de código
    • Compartir en las retrospectivas semanales casos de problemas causados por código de IA (un "registro de fallos")
  • Usar activamente reglas personalizadas
    • La mayoría de las herramientas de IA permiten configurar un conjunto de reglas que se envía junto con el prompt
    • Si el equipo mejora ese ruleset en conjunto, puede reducir los errores de la IA
    • Aun así, cuanto más larga es la sesión, más aumenta la posibilidad de que ignore las reglas
  • Fomentar una cultura de equipo basada en la confianza y la comunicación
    • Adoptar IA es un cambio nuevo, y hay que reconocer que todos son principiantes en esto
    • Presiones del tipo "como ya hay IA, hazlo más rápido" aumentan el riesgo para la calidad
    • En equipos con seguridad psicológica, compartir problemas y aprender ocurre con mayor facilidad

[bus710]

Quienes usan esa herramienta, más allá de su nivel de capacidad, al final todos serán desarrolladores.... Me parece un poco raro que se promocione como si en el futuro ya no fueran necesarios los desarrolladores.

[prunusnira]

No sé cómo vaya a evolucionar en el futuro, pero por ahora no me parece muy bueno como para usarlo de forma generalizada... Hace poco probé Cursor y ni siquiera lograba resolver bien algo tan básico como la ruta de importación de archivos. Aun así, me sorprendió un poco que pudiera anticipar hasta cierto punto lo que yo quería crear.

[daddy]

Cuando ocurre un error de memoria durante un build de Docker, en vez de preguntarnos desde el principio por qué se estaba usando tanta memoria, aumentamos la configuración de memoria
-> Esto es... porque ya lo hemos hecho así en muchísimos casos.
-> La IA de ahora somos nosotros en el pasado

[GN⁺]

Comentarios en Hacker News

• Últimamente uso Cursor para la mayor parte del desarrollo. Este artículo se parece mucho a mi experiencia

  • Siento que los agentes de IA se quedaron detenidos más o menos en 2021. Si instalas un paquete nuevo, Claude vuelve a paquetes o implementaciones viejas que eran populares hace 4 años. Corregir eso es muy frustrante. Dar instrucciones claras puede aliviar el problema, pero no lo resuelve
  • La imprevisibilidad de estos errores es especialmente desafiante. Hace unos meses usé Claude para crear una web app útil de "un solo intento". Tenía funcionalidad completa y era sorprendentemente sofisticada. Si la hubiera hecho yo solo, me habría tomado semanas o fines de semana. Pero cuando le pedí que actualizara el favicon usando los archivos proporcionados, dio vueltas sin servir de nada durante una hora (al final lo resolví yo mismo en unos minutos). Hace unos días intenté volver a crear una web app de alcance similar. Después de unas 4 horas lidiando con el agente, ya estaba listo para tirar todo el código
  • Este enfoque me da el valor de perseguir proyectos que no habría intentado por falta de tiempo, experiencia o motivación. Reducir la fricción es emocionante, pero crear algo significativo sigue siendo difícil. Todavía hace falta un esfuerzo considerable para construir un MVP sofisticado
  • Sigo pensando en la liebre y la tortuga. Confiar en agentes de IA es tentador porque al principio parece que avanzas mucho más rápido. Pero al final queda la sensación de que habría logrado un progreso más sólido yendo lento y con atención al detalle. Cuando construyo algo a mano, casi nunca tengo que retroceder o abandonar todo el enfoque. Con un enfoque guiado por IA, puedes moverte 10 veces más rápido, pero puedes terminar desechando como el 70% del trabajo en el proceso
  • Por estas experiencias, no me imagino que en un año la IA vaya a escribir de forma autónoma el 90% del código. Sí puede ayudar con el 90% de la escritura de código
  • El entorno actual se parece al ciclo de hype de los autos autónomos. Ha habido muchas promesas atrevidas y avances reales, pero no veo un mundo en los próximos 5 años donde la IA escriba por sí sola software útil

• Yo uso la IA así: como asistente de escritura dentro del IDE, y me responde como un pato de goma muy genial y sofisticado

  • A menudo repito discusiones sobre fragmentos de código específicos. Normalmente se los doy con muy poco contexto, los voy refinando hasta que la función funciona bien y luego los presento dentro de un contexto más amplio (o esa parte la manejo yo mismo)
  • No la uso así: no la uso como un agente que debe alcanzar por sí mismo objetivos amplios
  • Razón: el tiempo y esfuerzo que hay que invertir para asegurarse de que la salida del sistema agente realmente coincida con lo que uno quiere lograr es demasiado grande. Por todas las razones explicadas en este excelente artículo
  • Paradójicamente, usar la IA como una herramienta de escritura muy capaz acelera bastante mi flujo de trabajo. Así que, hasta cierto punto, una IA menos agentiva me vuelve más crítico, y me hace más crítico del tiempo adicional que tendría que invertir para adaptarme a las rarezas de la IA agentiva

• No lo entiendo para nada

  • No entiendo por qué desarrolladores con experiencia se entusiasman con atarse a una experiencia tan obviamente mala e insatisfactoria
  • A mí me gusta escribir código y resolver problemas. Por eso elegí el desarrollo de software como profesión

• Ejemplo: cuando ocurrió un error de memoria durante una compilación de Docker, en vez de preguntarse desde el principio por qué se estaba usando tanta memoria, aumentó la configuración de memoria

  • La IA de verdad es igual a nosotros

• Las habilidades de desarrollo siguen siendo esenciales — si no sabes manejar, no puedes conducir. Pero, ¿qué pasa con la energía del desarrollador? Antes de la IA, solo podía programar unas 2 horas al día (tiempo real escribiendo código). Pero con Claude Code puedo programar fácilmente 5 horas seguidas sin parar. Se siente como andar en una bicicleta eléctrica en vez de una bicicleta normal. La IA se siente como la bicicleta para la mente de Steve Jobs: no me reemplaza, pero ahora puedo llegar mucho más lejos y más rápido

• Este diagrama me representa muchísimo — nuestro equipo marca todas las casillas de aquí. ¡Y eso que todavía no usamos IA! Imaginen cuando al fin la usemos...

  • "Requisitos mal entendidos" e "implementación demasiado compleja" son prácticamente nuestra mascota. Poco a poco vamos desenredando ese caos con mejores conversaciones iniciales y revisiones iterativas. Pero los hábitos no desaparecen fácil. ¿Hay alguien que navegue estas trampas sin ayuda de IA?

• Para mí no es evidente lo obvio: usar IA a mi alrededor

  • Muchas veces hay que construir y mantener herramientas como tooling de desarrollo, introspección, logging, transformaciones, etc. He tenido mucha suerte usando agentes para crear y modificar eso. Por ejemplo, herramientas que recolectan datos y juntan logs en un sistema de planeación personalizado
  • Hay mucho boilerplate generado fuera de la ruta crítica al construir estas herramientas. La mayoría de los días no tengo ganas de hacer eso

• Hay que pilotear mucho a la IA, pero sigo siendo optimista en que mejores prompts llevarán a mejores agentes

  • Tomemos el ejemplo del artículo: reutilización de código. Cuando escribes código, de forma inconsciente tienes un inventario mental del código que ya existe. Inconscientemente te preguntas: "¿esta tarea nueva se parece mucho a código existente que ya funciona y está probado?". No he revisado el detalle de los prompts iniciales que reciben los agentes de programación, pero mi intuición es que sería bueno agregar un prompt que le indique al agente mantener un inventario de lo que hay en el codebase, y que al planear una nueva tanda de código contraste los requisitos de la tarea nueva con lo que ya existe
  • Sí, eso agrega muchos ciclos de cómputo al proceso de planificación. Pero honestamente hay que decir: "ese es el costo de que el agente escriba código". Mejor planificación > mejor capacidad para resolver problemas

• Quiero poner como prefacio que las herramientas de IA siempre son malas para las cosas que enumeré

  • Parece que ahí falta un "not". ¿Por qué pondría como prefacio que siempre son malas? Lo contrario tiene más sentido
  • También hay un error gramatical: dice "effected" en vez de "affected"

• ¿Martin Fowler ahora está alquilando espacio en su sitio web?