En la era en que la IA produce código a raudales, cuando baje la marea se verá quién estaba nadando desnudo
(evan-moon.github.io)Resumen clave
- En apenas 3 años desde la aparición de ChatGPT, la jornada de los desarrolladores se está desplazando de "escribir código" a "revisar la salida de la IA"
- El rol del desarrollador no está desapareciendo; más bien, el centro de gravedad se mueve de quien escribe código a quien lo revisa y aprueba
- La IA no es una entidad legal y no puede asumir responsabilidad; además, regulaciones como la EU AI Act se están reforzando en la dirección de atribuir la responsabilidad a los humanos
- En la era de la IA, la capacidad clave no es la técnica de prompts, sino predecir el costo de cambios a largo plazo, juzgar abstracciones y verbalizar conocimiento tácito, que en esencia son las mismas cualidades que hoy necesita un buen desarrollador
- Explicado con el concepto de complejidad accidental vs. complejidad esencial de Fred Brooks, lo que la IA resuelve es solo la complejidad accidental, mientras que la complejidad esencial del dominio sigue requiriendo juicio humano
- La vigencia de la pericia en herramientas (como prompt engineering) está atada al ciclo de reemplazo de herramientas, pero la capacidad de tomar decisiones de diseño y verbalizar conocimiento tácito sigue siendo válida mientras exista la complejidad esencial del software
Resumen detallado
Tres años después de ChatGPT
- A finales de 2022, cuando apareció ChatGPT, no se anticipaba que avanzaría a esta velocidad
- Definición tradicional de desarrollador: una persona que realiza todo el proceso de "analizar requisitos en lenguaje natural → diseñar → implementar directamente"
- Ahora, gran parte del día se va en "dar contexto a la IA → leer, corregir y volver a pedir el código generado"
- Los agentes de codificación con IA ya superaron el nivel de simple apoyo y, a nivel de funciones o módulos, alcanzan una calidad difícil de distinguir del código escrito por personas
De autor a tomador de decisiones
- La actividad de producir código se está moviendo de "escribir código directamente" a "juzgar el código"
- "Juzgar" no significa solo comprobar si la salida de la IA coincide con lo esperado, sino verificar si la intención de negocio fue traducida correctamente a una implementación técnica
- La pregunta clave es: "Si un bug en pagos aparece en código escrito por IA, ¿quién asume la responsabilidad?"
- Como la IA no es una entidad legal, los responsables son el desarrollador y la organización que revisaron y aprobaron ese código
- La EU AI Act, en vigor desde 2024, obliga a la supervisión humana de sistemas de IA en áreas de alto riesgo como salud, finanzas e infraestructura
- En accidentes de vehículos autónomos la responsabilidad recae en fabricante y conductor; en IA médica aprobada por la FDA, la decisión final sigue siendo del médico; en el Flash Crash de 2010, el sujeto regulado fue quien operaba el algoritmo
- Cuanto más sofisticada se vuelve la automatización, la estructura de responsabilidad no se vuelve más difusa; al contrario, tiende a atribuirse de forma más clara al lado humano
Capacidades que se le exigen al desarrollador en la era de la IA
① Capacidad de predecir el costo de cambios a largo plazo
- La IA está optimizada para producir "código que funciona" (reproduce los patrones más frecuentes de los datos de entrenamiento)
- El código que funciona hoy y el que sigue siendo fácil de mantener dentro de 6 meses responden a criterios completamente distintos
- El costo de un mal diseño no aparece cuando se escribe el código, sino cuando surge la necesidad de cambiarlo
- En LinkedIn aumentan las publicaciones del tipo "lo hicimos con IA pero era imposible de mantener y tuvimos que contratar desarrolladores" o "terminamos abandonándolo porque no podíamos seguir agregando funciones"
② Capacidad de evaluar el código desde múltiples ángulos
- Más allá de la corrección funcional (que puede validarse con pruebas), hay que considerar al mismo tiempo calidad estructural, implicaciones de rendimiento y aspectos de seguridad
- Cuanto más rápido genera código la IA, más fácil es que se rompa el equilibrio entre velocidad de producción y capacidad de revisión
- Cuando las personas escribían el código directamente, había un límite físico a la cantidad producida, pero la IA puede generar cientos de líneas en segundos
- Si faltan criterios de revisión, esquemas de revisión en paralelo y compuertas automatizadas, la deuda técnica se acumula aún más rápido
- Muchas empresas no sienten un aumento de productividad tras adoptar IA porque la producción de código se aceleró, pero la revisión del código generado por IA se volvió el cuello de botella
③ Capacidad de abstracción
- La IA también puede definir interfaces, separar clases y dividir módulos, y formalmente lo hace bien
- La diferencia decisiva: la abstracción de la IA se basa en promedios estadísticos; la abstracción de un desarrollador experimentado se basa en juzgar trade-offs bajo recursos limitados y un futuro incierto
- Lo peligroso del código generado por IA es que a simple vista se ve bien: los archivos están divididos de manera razonable, los nombres siguen convenciones y los patrones resultan familiares
- El problema aparece cuando hay que modificarlo: "queríamos agregar un nuevo medio de pago y recién ahí nos dimos cuenta de que teníamos que tocar al mismo tiempo varias partes de una estructura que ‘se veía limpia’"
- Ejemplo en frontend: la IA puede meter data fetching, manejo de estado y renderizado de UI dentro de un solo componente gigantesco o, al revés, crear 3 custom hooks + un context provider para un gráfico sencillo
④ Capacidad de hacer explícito el conocimiento tácito
- Para dar instrucciones precisas a la IA, hay que poder convertir la intuición de "algo se siente raro" en lenguaje concreto como "esta función tiene dos responsabilidades"
- No se trata de técnicas formales de prompts como few-shot o chain-of-thought, sino de definir con claridad qué se debe construir y juzgar qué contexto es importante para transmitirlo
- Vida útil de la pericia en herramientas: está atada al ciclo de reemplazo de herramientas (
jQuery → React,Webpack → Vite) - Vida útil de la capacidad de juicio de diseño y de verbalización del conocimiento tácito: sigue vigente mientras exista la complejidad esencial del software
La necesidad de diseñar una práctica deliberada
- Se dice "concéntrate en lo que la herramienta no puede hacer", pero paradójicamente cada vez hay menos oportunidades para desarrollar justo eso
① Dos puntos que no deberían delegarse a la IA: diseño y revisión
- En la etapa previa a escribir código, si antes de teclear el prompt defines primero la interfaz y los límites de responsabilidad, luego puedes comparar la salida de la IA con tus propias decisiones de diseño
- El hábito de dejarle a la IA la revisión de PR y aprobar si no marca problemas es como "salir al patio en clase de educación física, quedarse sentado en la banca y luego volver al salón"
② Tiempo para programar intencionalmente por cuenta propia
- El sentido del diseño nace cuando se conoce el dolor de implementar. El dolor que no se vive no se convierte en criterio
- Para un desarrollador junior, revisar código generado por IA es parecido a "pedirle a alguien que todavía está aprendiendo a manejar que evalúe el criterio de un auto autónomo"
- La capacidad de programar en el futuro no será tanto una tarea diaria, sino un entrenamiento para conservar el juicio (el proceso de sacar una licencia de revisor)
③ Practicar poner en palabras el "por qué"
- Si te quedas en "se siente raro", es intuición; si llegas a "esta función tiene dos responsabilidades", ya es lenguaje
- Aunque el código generado por IA funcione, no detenerse ahí y hacerse el hábito de preguntar: "¿por qué eligió esta estructura?", "si hubiera sido otra estructura, ¿cuáles serían los trade-offs?"
Al final, la esencia no cambió
- Fred Brooks (1986): complejidad accidental (limitaciones de las herramientas) vs. complejidad esencial (inherente al problema mismo)
- Lo que la IA resuelve es la complejidad accidental: boilerplate, patrones repetitivos, errores de sintaxis
- La complejidad esencial (ambigüedad de los requisitos de negocio, equilibrio entre objetivos de diseño en conflicto, incertidumbre sobre cambios futuros) no desaparece aunque la IA avance
- Mientras el ser humano siga siendo el sujeto del juicio y de la responsabilidad, la esencia de las capacidades necesarias para juzgar no cambiará
- Cuanto más se automatice la producción de código, más se destacará el peso del criterio para revisar lo producido
14 comentarios
¡Gracias por compartir tan buenas opiniones!
Cuando mencioné la "responsabilidad" en el texto, no fue porque los humanos cometan menos errores que la IA en todos los aspectos, sino porque los sistemas legales y éticos de la sociedad moderna solo contemplan a los humanos (o a las personas jurídicas) como "sujetos responsables".
Como dijo gcback, si se demuestra una seguridad estadística, en el futuro incluso podría cambiar el propio sistema de responsabilidades, pero al menos en el corto plazo considero que el dilema social de "quién irá a la cárcel o quién pagará una indemnización por un accidente causado por la IA" difícilmente podrá seguir el ritmo del avance tecnológico..!
Pienso lo mismo. Lo leí con gusto.
¿De verdad se está retirando el agua, o más bien está subiendo? Eso de las "capacidades que se le exigen a un desarrollador en la era de la IA"... no sé. Supongo que sí, si es que los desarrolladores siguen existiendo.
Desde la posición de alguien que usa IA en el trabajo real, eso de pasar de desarrollo con IA -> supervisión de resultados de IA realmente me resuena mucho.
Y la IA también está ayudando mucho a resolver la complejidad esencial. [Verificación de contradicciones al analizar requisitos, detección de duplicados, preguntas sobre el valor esencial]
Necesitamos que haya más personas que confíen ciegamente en la IA.
¿Por qué será?
Creo que esto también será una etapa de transición.
Porque incluso entre los entrenadores de fútbol famosos, muchos no fueron exjugadores.
No es un egresado de Seúl, pero creo que se hizo famoso porque tiene una gran capacidad de comprensión.
Pero como se habla de fútbol, me viene a la mente Chung Mong-gyu.
Es porque tiene las cualidades suficientes para dirigir un equipo de fútbol aunque no haya sido jugador profesional, y porque quien puede asumir la responsabilidad por el resultado del partido es quien dirige.
Sí, también hay entrenadores que no fueron jugadores.
Pero esos entrenadores no destacan por no haber sido jugadores, sino... porque, aun sin venir de una carrera como jugadores, parecen tener una visión superior incluso a la de muchos jugadores. En ese campo, de hecho, casi se les podría llamar "superhumanos".
Yo también estoy de acuerdo
Últimamente, viendo enfoques como Harness o de tipo loop, parece que la dirección es que las personas solo den las especificaciones y hasta la revisión o el QA los hagan entre AIs por su cuenta
Estoy de acuerdo.
Al final, como el nivel de revisión y verificación también inevitablemente podrá superar al de los humanos con la IA, parece que terminará siendo menor que el costo actual de que una persona asuma la responsabilidad.
Ya sea una persona o una IA, es un juego en el que gana, estadísticamente, quien comete menos errores.
¿Democratización de dirigir? Jaja, se dirige porque se tienen las aptitudes; no es que alguien vaya a dirigir aunque no las tenga.