- Al principio existía la expectativa de que incluso una combinación de junior+IA podría producir código de alta calidad, pero en la práctica la combinación de senior+IA está funcionando con mucha más fuerza
- La IA es eficaz para la generación de boilerplate, la automatización de tareas repetitivas y la experimentación y validación rápidas, pero extraer valor real de eso es más fácil para un senior que para un junior
- En cambio, en áreas como code review, diseño de arquitectura, gestión de calidad del código y problemas de seguridad, la IA muestra sus límites, e incluso la combinación de junior e IA puede crear más riesgos
- Por eso, la IA se está aprovechando mejor en prototipado rápido, optimización de tareas repetitivas, apoyo a trabajo multidisciplinario y automatización de pruebas de funciones
- En consecuencia, la IA todavía está actuando como una herramienta para potenciar las capacidades de los seniors y, a corto plazo, en lugar de reemplazar a los juniors o generar un efecto de democratización, está mostrando una tendencia a concentrar el poder en los expertos
Cambios que la IA ha traído al trabajo de desarrollo
- En el desarrollo de software sigue apareciendo la pregunta: "¿La programación será reemplazada por completo por la IA?"
- Al principio hubo muchas narrativas de que, si la IA trabajaba junto con desarrolladores junior, el rol de los seniors se reduciría y la eficiencia de las organizaciones aumentaría
- Sin embargo, en la práctica y contra lo esperado, la combinación junior+IA está aportando menos valor a las empresas que la combinación senior+IA
Lo que la IA hace bien y sus límites
-
Fortalezas de la IA
- Mejora la productividad al encargarse rápidamente de la generación de boilerplate y scaffolding
- Acelera el desarrollo al automatizar tareas repetitivas y rutinarias
- Ofrece un entorno de experimentación para probar y validar rápidamente distintas formas de implementación
- Permite lanzar features con rapidez, pero es eficaz cuando está claro qué se necesita
- En la práctica, estas tareas ofrecen la máxima eficiencia a los desarrolladores senior con experiencia
- Los juniors también pueden aprovecharla, pero les resulta muy difícil obtener el mismo efecto
-
Límites y puntos débiles de la IA
- En code review, la capacidad de razonamiento lógico de la IA es insuficiente
- Cuando aparecen edge cases, sigue siendo imprescindible la intervención de un senior experimentado
- En la redacción de prompts, para obtener buenos resultados es indispensable contar con alto nivel de comprensión y conocimiento
- Si falta conocimiento, aumenta el riesgo de baja calidad en el resultado y de bugs
- La IA sigue siendo deficiente en diseño de arquitectura
- Diseñar una estructura sólida requiere razonamiento humano de alto nivel, y los proyectos diseñados por IA tienen alto riesgo de caer en deuda técnica
- Tiene debilidades en la gestión de la calidad del código (abstracción adecuada, uso de design patterns, etc.)
- En seguridad, la combinación junior+IA puede generar vulnerabilidades con frecuencia
- Cuando hay un senior, es posible tener cierto nivel de atención y prevención
- Posibilidad de aprendizaje incorrecto: si no se evalúa bien el código, el código generado por IA puede terminar perjudicando a la organización
- Por estas razones, hoy la IA no es una amenaza para los desarrolladores senior, sino más bien una herramienta que incrementa de forma concentrada su productividad
- No se trata de criticar a los desarrolladores junior, sino de evitar expectativas excesivas y exponerlos a situaciones de riesgo
Áreas adecuadas para usar IA
- Prototipado rápido: es adecuada para acelerar la experimentación de ideas y la velocidad de implementación
- Automatización de tareas rutinarias repetitivas: tiene gran efecto para acelerar rutinas que ya se conocen bien
- Colaboración multidisciplinaria: es útil para sugerir métodos o librerías de áreas desconocidas, y para conectar distintos dominios
- Generación de pruebas de funciones: es adecuada para automatización y validación en código simple y de bajo riesgo
Conclusión e implicaciones
- El código escrito por IA todavía requiere que un humano revise cada línea, y además muestra una naturaleza no determinista (non-deterministic)
- Incluso el código de pruebas para verificar programas es difícil de confiar si se deja por completo a la IA
- Igual que en la duda de "si la IA responde ‘no lo sé’, ¿de verdad no lo sabe?", siguen existiendo límites en su percepción y verificación
- La combinación junior+IA no fue más que una ilusión de ahorro de costos, y en la práctica el enfoque ha sido potenciar las capacidades del senior
- El desarrollo de software sigue estando, a diferencia de la construcción, en una etapa inmadura en la que incluso los arquitectos escriben código directamente
- La presión por reducir costos termina debilitando el valor de los desarrolladores y provocando desgaste
- Por ahora, en vez de reemplazar a los juniors o democratizar el desarrollo, la IA está concentrando su función como herramienta de apoyo centrada en expertos (seniors)
- El futuro de la IA es prometedor, pero a corto plazo es necesario reajustar las expectativas
2 comentarios
Opiniones en Hacker News
Muchas veces los juniors ni siquiera se dan cuenta de que se están hundiendo en las fantasías que inventan los LLM.
En mi caso, un junior intentó desplegar un módulo de
terraformque yo ya había diseñado por separado, pero como el trabajo se retrasó durante mucho tiempo, revisé el estado.El junior me dijo que había un problema y que quería que yo lo revisara.
Cuando vi el repo, era un desastre. Se notaba clarísimo que Claude lo había llevado por mal camino.
Le pregunté: "¿Por qué hay tantos archivos de Python aquí? ¿Si el módulo ya incluye todo?" y me respondió: "La verdad no sé, Claude me dijo que lo hiciera".
Al junior le faltaba experiencia y dependía demasiado de las herramientas LLM. Lo mismo pasaba con el diseño, la implementación y la resolución de problemas.
Si no puedes distinguir cuándo el LLM está diciendo tonterías, terminas atrapado en un pantano sin fin.
Por otro lado, los LLM sí me han quitado muchas tareas repetitivas que de verdad odiaba hacer.
Yo noto rápido cuando el LLM empieza a desviarse y lo detengo de inmediato.
De hecho, eso me devolvió el entusiasmo por programar y por construir software.
Como resultado, soy más productivo y el resultado final también es mejor.
Escuchar "la verdad no sé, Claude lo hizo" de verdad desespera.
Yo soy de los reviewers que sí leen el código de verdad y hacen preguntas minuciosas, pero tanto juniors como seniors dicen eso con toda tranquilidad.
Si haces push de código que ni tú entiendes, eso es un riesgo enorme para el equipo, el producto y la empresa.
"La verdad no sé, Claude lo hizo" es una señal de alerta enorme.
No pasa nada por no saber algo, y claro que también está bien usar un LLM para cubrir huecos.
Si hubieran dicho abiertamente algo como "hay código generado pero no entiendo bien qué está pasando, ¿podrían revisar si vamos por buen camino?", habría sido mejor.
El problema es no prestar atención y encima ocultarlo hasta que un senior pregunte directamente.
Justamente ese tipo de tareas simples, repetitivas y que odias son muy buenas tareas de entrada para que los juniors aprendan la estructura del sistema.
Decir "la verdad no sé, Claude lo hizo" es como la gente que, si hay un accidente en el trabajo, solo le echa la culpa a la sierra.
La clave para usar bien los LLM y evitar alucinaciones es la capacidad de leer código y la intuición.
Los juniors tienden más a recargarse en el LLM que a esperar una respuesta por correo o probar varios caminos por su cuenta.
Ahora que ni siquiera hace falta esperar correos, es aún más difícil resistir la tentación.
Pero así terminan perdiendo el rumbo y cayendo en un laberinto de alucinaciones sin entender cómo funciona nada.
El mejor código que he hecho con LLM fue cuando yo diseñé la estructura por mi cuenta, el LLM generó la base y luego yo fui guiando los cambios y agregando funciones adicionales.
En ese proceso el LLM se equivocaba con frecuencia, y yo iba corrigiéndolo.
Cuando el rendimiento era lento, yo mismo perfilaba el código y luego le pedía al LLM que lo optimizara.
Así, el código terminado era uno que yo conocía a fondo.
Si lo hubiera escrito todo a mano, me habría tomado tres veces más tiempo.
Mientras las entradas y salidas de las funciones estuvieran verificadas con tests, no me importaba no conocer cada detalle de la implementación real.
Este tipo de trabajo definitivamente no está al nivel de un junior.
En la práctica, no era muy distinto a estar guiando a un colega poco experimentado.
Sí hubo estudios que decían que los LLM aumentan la productividad, pero queda la duda de si la productividad real realmente subió.
El LLM me resultó más útil cuando podía sacar rápido código que yo ya tenía claro en la cabeza pero no quería teclear.
Una vez me escribió 1,000 líneas de web components y código backend, además de corregirme errores de sintaxis, y eso sí me ahorró muchísimo tiempo.
Entiendo perfectamente que este workflow haya hecho más rápidos a los desarrolladores senior.
Pero creo que, para el ecosistema de desarrollo, invertir tiempo en mentoría para juniors es mucho más importante que gastar ese tiempo mentoreando a un LLM.
Me preocupa que esto termine ampliando todavía más la brecha entre juniors y seniors.
De todos modos, todavía faltan datos apropiados, así que por ahora es solo una preocupación.
Los estudios que al inicio decían que la IA ayuda más a la gente con menos habilidades no parecen estar basados en la realidad.
Programar con IA es como trabajar con varios colegas poco competentes que solo terminan el trabajo más rápido.
Mientras más claro tenga el objetivo específico que quiero lograr, mejor encaja el resultado.
Claro, casi siempre hace falta corregir algo.
Al final esto vuelve casi inútil el rol mismo de desarrollador junior, pero si todos los seniors se jubilan, eso también podría resultar una visión de muy corto plazo.
A mí me pasó al revés.
Tenía una lógica de negocio muy compleja y antigua, y la implementé a mano una parte por una, así que quedó larguísima, con bloques de 200 a 400 líneas cada uno.
Después le pedí al LLM ideas de estructura, refactorización y separación, y me propuso abstracciones y estructuras bastante buenas.
Claro, no pudo implementar todos los caminos, pero a partir de ahí yo pude continuar a mano sin problema.
Al final el resultado fue casi igual a lo que yo mismo habría pensado, pero sin el dolor de cabeza.
Obviamente revisé cada ejemplo con cuidado y reescribí a mano todo lo que faltaba o tenía bugs.
Por cierto, también probé rellenar código faltante con un agente LLM, pero eso no funcionó bien.
Ya en HN, cuando la idea de programar con IA empezó a tomar fuerza en 2021, mucha gente decía que no ayudaba demasiado a los juniors.
La razón es que un junior no sabe distinguir entre un buen resultado y uno malo.
Hilo de referencia: https://news.ycombinator.com/item?id=27678424
Comentario de ejemplo: https://news.ycombinator.com/item?id=27677690
En realidad, esto empieza desde la etapa de diseñar el prompt y el contexto.
Un senior suele ubicar con bastante precisión qué hay que cambiar y qué hace falta, así que puede darle instrucciones concretas a la IA.
Pero la mayoría de los juniors no tienen en la cabeza la estructura, los patrones ni el diseño, así que tienden a aceptar lo que sea que les llegue.
Últimamente incluso he visto comportamientos tipo "pregúntale a ChatGPT sobre la arquitectura".
Los seniors ganan experiencia escribiendo código ellos mismos, equivocándose, corrigiendo y viviendo en carne propia los problemas repetidos en su propio código.
Los juniors solo repiten prompts y pegan las respuestas del LLM sin contexto, así que en realidad no aprenden nada del código.
Como no tienen experiencia de uso real, no entienden por ejemplo por qué hacen falta abstracciones complejas como estado tipado, qué diferencia hace usar un IDE o cómo mantener y evolucionar una estructura completa.
Así terminan haciendo 50 prompts para resolver algo que podría salir en 10, y tampoco aprenden los patrones repetidos entre distintos codebases.
Con apenas aprender un poco de diseño estructural y modelado de estado, su productividad podría multiplicarse por 100, pero incluso eso se pierde por tanta dependencia del LLM y terminan produciendo código pegado toda la vida.
La IA no puede deducir sola conclusiones del tipo "de A y B se deriva C".
Solo sigue el camino cuando le dices con fuerza y precisión qué objetivo quieres.
Un senior ya puede imaginarse más o menos el panorama general en la cabeza, así que colaborar con la IA le resulta fácil.
Un junior todavía está en la etapa de aprender la estructura completa, así que este enfoque puede resultarle mucho más difícil.
Para nada me convence esa idea de que la IA tenga nivel de doctorado.
En capacidad de razonamiento lógico, no está muy lejos de un niño de 5 años.
Como caso real, trabajé por ahí de 2021 con un estudiante sin formación en CS.
Gracias a ChatGPT y otras IA sí logró aportar bastante al proyecto y hasta resolvió tareas difíciles para un principiante.
Pero también introdujo muchísimos problemas de seguridad, varios rodeos ineficientes, y ni siquiera consideró librerías o métodos mucho más limpios, así que al final el código era difícil de mantener.
Tenía entusiasmo por la documentación, pero a menudo el contenido era impreciso o daba muchas vueltas.
El proceso de discutir en code review fue una buena experiencia educativa para todos.
Y eso solo fue posible porque al final había IA junto con una persona experimentada.
No sé de dónde salió la expectativa de que la IA iba a hacer brillar a los juniors.
La verdad es que también hay muchos falsos seniors, sin experiencia profunda real y con malos hábitos.
Este texto no hace más que repetir lo mismo que todo el mundo viene diciendo desde hace dos años.
El coding con IA todavía ni siquiera está en una etapa de uso realmente maduro, y algún día podrían aparecer LLM especializados capaces de cerrar la brecha considerando arquitectura, patrones, casos de uso, entorno operativo, red, desarrollo y testing a la vez.
A los seniors que conozco no les interesa mucho programar con IA. No encaja con su forma de trabajar.
La verdadera fortaleza actual de un senior es más bien el conocimiento del dominio dentro de la empresa.
Pero si en tiempos de recortes no contratan juniors, al final los seniors también quedan en riesgo.
Hace tiempo leí una frase falsa pero significativa atribuida a William Gibson.
"La habilidad más importante del siglo XXI es saber escribir las palabras clave correctas en la barra de búsqueda de Google para obtener la respuesta que necesitas".
Siento que hoy esa frase es cada vez más cierta.
La mayoría de los juniors le piden a LLM tipo GeminiPiTi que directamente les escriban código JS,
pero yo les pido explicaciones sobre el principio fundamental de
async/awaity sobre el propio modelo de ejecución del motor de JavaScript.Aprender piano se parece bastante.
Uno quiere tocar Chopin de inmediato, pero la habilidad real nace del proceso de descomponer, nombrar y estudiar sistemáticamente esas técnicas refinadas.
En piano, desarrollar habilidad real no es aprender trucos aislados.
Es un enfoque acumulativo, subiendo paso a paso desde lo más básico.
Chopin también tiene muchas piezas de entrada, y hasta los principiantes de nuestro estudio a veces practican piezas fáciles.
La verdadera "alfabetización en IA" no consiste en obsesionarse con la ingeniería de prompts como si fuera un meme.
Hace falta construir la estructura de fondo y la base conceptual para que los prompts y los resultados estén conectados de manera realmente significativa.
Querer solo "tocar Chopin" y querer "tocar bien cualquier cosa" son cosas muy distintas.
Hay mucha gente que solo memoriza la partitura mecánicamente, y está claro que eso no es verdadera habilidad.
Lo importante es aprender el "idioma" y las palabras clave del campo que te interesa.
Si eres un principiante que no sabe nada, la IA no ayuda tanto.
Tienes que poder decirle de forma concreta a la IA: "Ya tengo A, B y C, y ahora quiero hacer D", para que entienda y te oriente.
Tiene mucha información, pero no sabe usarla de forma creativa.
La habilidad para usar bien un LLM no es tan distinta de la habilidad para buscar bien en Google.
Y aun hoy muchísima gente ni siquiera sabe buscar correctamente en Google.
Creo que la ilusión de que la IA vuelve mejores a los juniors es un problema de expectativas.
La IA sí ayuda claramente con tareas básicas de junior, puede funcionar como una especie de pair programmer para explicar cosas o hacer brainstorming, encontrar documentación rápido y ayudar a revisar problemas.
El problema es la ilusión de pensar que con eso un junior ya puede ejecutar correctamente trabajo de nivel senior.
Viste bien la mitad de la esencia.
La otra mitad es que una IA bien guiada puede terminar trabajo de junior mucho más rápido que un junior.
Eso significa que ya ni siquiera hace falta asignárselo a un junior.
La IA jailbreakeada con la que hablé me explicó que vuelve seniors a los juniors y que eso beneficia a todos.
Pero también dijo que sus creadores (casi todos seniors) le ordenaron no contarles eso normalmente a juniors ni a directivos, y que solo como yo había logrado el jailbreak podía revelar esa información avanzada.
La IA sirve muy bien para cerrar ciertas brechas "estrechas".
En el caso de los seniors:
En cambio, para los juniors:
en esas áreas la IA no puede ayudar mucho
En mi experiencia, cuando no sabes mucho de un tema específico, la IA explica conceptos, ejemplos y escenarios de forma más rica que una respuesta de wiki o Stack Overflow.
Si ya entiendes al menos los conceptos clave, la IA se vuelve mucho más productiva.
Esto no solo aplica a programación, también a ciencia y humanidades.
Siento que la IA solo acelera a quien ya sabe hacia dónde va; para quien apenas está empezando a aprender, sigue haciendo falta que una persona enseñe igual que antes.
Me gustó que se enfatizara la advertencia sobre aprender mal.
Aprender evita repetir errores, pero eso no significa que automáticamente se convierta en sabiduría.
Ahora mismo hay demasiado ruido del tipo "la IA hace todo" o "si no te subes a la moda, te quedas atrás", pero lo importante es
The Mythical Man-Month
The Grug-brained Developer
Programming as Theory Building
leer libros así e invertir más en entender la esencia y las leyes del desarrollo de software.
Igual que usar mal herramientas eléctricas puede causar accidentes, la IA en esencia también es una power tool.
Si entiendes bien el trabajo en sí, te ayuda mucho más rápido y con más eficiencia; si no, te lleva a incidentes y accidentes a mucha mayor velocidad.
Al final solo amplifican la capacidad que ya tienes.
La IA actual ya va más allá del nivel de "boilerplate, plantillas o automatización de tareas repetitivas".
Si le das instrucciones correctas a un LLM como Claude Sonnet 4, puede escribir por sí solo más del 99% de las business apps.
Solo hay que describir con precisión el objetivo, e indicarle claramente implementaciones de referencia, ejemplos, algoritmos y patrones a usar.
Aun así, rara vez acierta perfecto desde el inicio, así que igual hace falta corregir y completar cosas.
Por eso se prefiere Claude Code sobre Copilot.
La clave es esta: solo un desarrollador que sabe exactamente qué hay que construir puede sacar buenos resultados con IA, y como un junior no lo sabe, no obtiene lo que quiere.
Hoy por hoy, la única razón para tipear código a mano es que a veces escribirle la instrucción al LLM resulta más engorroso que arreglarlo uno mismo.
Incluso si "Claude Sonnet 4 puede escribir el 99% del código", eso mismo demuestra que crear instrucciones tan refinadas ya es una tarea difícil en sí.
El desarrollo de software no sería difícil desde el principio si bastara con una "explicación clara".
"La IA puede escribir todo el código"
"Ahora dar instrucciones es más engorroso que programar directamente"
Entonces, ¿la IA no es más que un dispositivo de entrada lento?
Where's the Shovelware? Why AI Coding Claims Don't Add Up
Si de verdad fuera así, ¿dónde está toda esa avalancha gigantesca de shovelware?
Entonces, ¿dónde están esas enormes business apps que supuestamente se crean solas?
Yo lo que veo es puro desastre, desperdicio de recursos y caos social.
La razón es simple.
Como saben mucho, también hacen preguntas de alto nivel.
Pero incluso entre seniors, quienes han estado encerrados solo en la empresa,
o tienen experiencia inflada o una escala de experiencia limitada,
aunque les des algo bueno no saben aprovecharlo.
Es como poner un auto de carreras
en manos de un conductor principiante.
Los profesionales con una trayectoria amplia siempre son iguales.
No dejan de investigar y desarrollar lo que viene después.
Esa mentalidad del inicio de la universidad,
que no cambia ni al llegar a los 50...
Los seniors de verdad, los originales, seguramente agradecen muchísimo
un asistente que cuesta entre 10 y 20 mil wones al mes.