- El CEO de AWS, Matt Garman, dijo que la idea de que la IA puede reemplazar a los empleados junior es "de las cosas más tontas que he escuchado"
- Señaló que los empleados junior son los de menor costo y, al mismo tiempo, los más proactivos en el uso de herramientas de IA, y subrayó que es indispensable ofrecer oportunidades de formación y aprendizaje
- También afirmó que medir el rendimiento de la IA por la cantidad de código escrito es una métrica sin sentido, y apuntó que es más importante tener menos código, pero de mayor calidad, que mucho código innecesario
- Dentro de AWS, más del 80% de los desarrolladores ya usan IA, aplicándola de distintas formas como pruebas unitarias, redacción de documentación, asistencia para programar y flujos de trabajo basados en agentes
- Garman proyectó que, en un entorno tecnológico que cambia con rapidez, lo que se necesitará a largo plazo es pensamiento crítico, creatividad y capacidad de aprendizaje, y que quienes tengan esas habilidades triunfarán en la era de la IA
Postura sobre la polémica del reemplazo de empleados junior
- Garman respondió con firmeza a algunos ejecutivos que sostienen que la IA puede reemplazar a todos los empleados junior
- Destacó que los empleados junior son “los que menos cuestan y, al mismo tiempo, los más entusiastas al usar IA”
- Insistió en la necesidad de formar talento al preguntar: “¿Qué pasará si dentro de 10 años nadie ha podido acumular experiencia?”
- Sostuvo que sigue siendo esencial contratar a recién graduados universitarios y enseñarles y entrenarlos en cómo resolver problemas
Crítica a la forma de uso de la IA y a las métricas
- Criticó la práctica de medir el desempeño de la IA con base en la cantidad de código escrito, calificándola como una “métrica inútil”
- Se puede generar una cantidad infinita de código, pero ese código puede ser de mala calidad
- Señaló que “muchas veces menos código es mejor”, cuestionando la obsesión por las métricas cuantitativas
- Según datos internos de AWS, más del 80% de los desarrolladores ya utiliza IA
- La usan de distintas maneras: automatización de pruebas unitarias, apoyo para redactar documentación, escritura parcial de código y colaboración basada en agentes
- La tasa de uso de estas herramientas de IA sigue aumentando cada semana
Consejos sobre educación y carrera profesional en la era de la IA
- Garman señaló como habilidades necesarias en la era de la IA el pensamiento crítico, la creatividad y la disposición para aprender
- No se trata de dominar una tecnología específica, sino del propio “aprender a aprender”
- Subrayó que lo clave es “saber pensar por uno mismo, descomponer problemas para resolverlos y tener la disposición de aprender cosas nuevas”
- Indicó que, como la tecnología avanza demasiado rápido, aprender solo una habilidad específica difícilmente sostendrá una carrera de 30 años
- Por ello, consideró que los educadores deben enseñar a los estudiantes a descomponer problemas y pensar, así como a mantener una actitud de aprendizaje continuo, y anticipó que quienes desarrollen estas capacidades prosperarán en la era de la IA
11 comentarios
Creo que ambas cosas deben analizarse bien.
Para operar una empresa se necesitan desarrolladores, y me parece que ahora mismo es una época difícil para que los desarrolladores junior consigan empleo.
En público se le echa la culpa a la IA, pero también influye que durante la pandemia se contrató masivamente y, en comparación con el éxito obtenido, en muchas empresas aumentó el costo total de personal; por esa carga han reducido las contrataciones. En ese contexto, como usar LLM está mostrando una eficiencia igual o incluso superior a la de asignar ciertas tareas a desarrolladores junior, creo que el mercado laboral en sí se ha achicado aún más.
Sin embargo, como también se menciona en el artículo, tiene que haber desarrolladores junior para que eventualmente puedan crecer y convertirse en desarrolladores senior.
Si no se contrata en la etapa junior, es una estructura en la que no pueden surgir desarrolladores senior.
Aun así, creo que en todo este proceso hace falta una coordinación considerable.
En el caso de las grandes empresas, quizá sea menos problemático porque ya tienen procesos establecidos, pero cuando llega un desarrollador junior, normalmente se le forma asignándole tareas secundarias o trabajo menor (tareas de la empresa en las que no pasa nada si falla) en lugar de ponerlo directamente en el núcleo del trabajo.
Pero desde la perspectiva de un desarrollador senior, cuanto menos estructurado esté todo, más difícil es orientar a un desarrollador junior.
Y, de forma irónica, para aprovechar un LLM conviene tener más conocimiento relacionado; no es que un desarrollador principiante vaya a obtener la misma eficiencia.
De hecho, no es posible reemplazar todo el trabajo de desarrollo con personal junior. Personas muy brillantes y geniales quizá podrían arreglárselas de alguna manera incluso sin desarrolladores senior. Pero si el trabajo empieza a concentrarse en esa persona, ¿podrá sostenerlo?
En otras palabras, creo que deben contratarse tanto desarrolladores senior como junior, y que en ese proceso debe haber una contratación flexible que considere la productividad y los costos laborales de la empresa, entre otras cosas.
Los que niegan este texto
son solo seniors de bajo nivel que, por su propia falta de nivel, solo han trabajado con juniors mediocres jajaja
Sin importar la experiencia, en la era de la IA las personas más inteligentes tienen una ventaja abrumadora.
Si una persona brillante recién entrada le mete con todo durante 1 o 2 años, se come sin problema a alguien con 10 años de experiencia promedio
Incluso sin IA, un recién graduado inteligente, si le mete duro 1 o 2 años, se podía comer sin problema a alguien promedio con 10 años de experiencia...
Da la impresión de que está diciendo algo como: “Los juniors son baratos y usan bien la IA, ¿entonces por qué reemplazarlos? ¡Reemplacemos a los seniors!”
Oh, sí, también se podría entender así.
Pura mierda jajaja
Uf...
Por favor, absténganse de comentar de esta manera. Esto no es DC Inside.
Aquí no es DC..
Qué manera de hablar.
Opiniones de Hacker News
Totalmente de acuerdo. Dicho eso, siento que para usar de verdad código generado por LLM tienes que volverte un verdadero mago del prompt. Yo solo lo uso a veces para depurar o para bosquejar rápido una UI. En cuanto a código real, el código escrito por LLM de verdad suele ser código espagueti, verboso, con riesgos serios de rendimiento y seguridad, y además malinterpreta por completo casi todos los patrones de diseño que le doy.
Cada vez me sorprende más ver posts escépticos sobre AI coding en Hacker News y Reddit. Parece que todos vivimos en mundos completamente distintos. Creo que parte de la causa también es la variedad de herramientas. Pienso que “usar código de LLM” significa algo diferente para cada persona. En concreto, parece que influye mucho qué LLM usas, qué contexto le das y qué IDE estás usando. Yo escribí personalmente 200 mil líneas de código B2B SaaS antes de que despegara el agentic coding. Ahora, en modo Sonnet 4 Agent, solo escribo yo alrededor del 20% del código diario y el otro 80% lo hacen interactive Sonnet en VS Code y GitHub Copilot Agents. Mientras más documentación hago en Markdown, mayor se vuelve esa proporción. Reviso y pruebo el resultado con mucho cuidado.
Me da curiosidad saber qué herramienta usas. Yo uso aider, e incluso usando modelos con fama de ser flojos para programar, como gpt-5, jamás he tenido la clase de experiencia que describes. De hecho, escribe código “bueno” y además se adapta bien al estilo del código existente. Escribir buenos prompts sí es muy importante, y en una base de código existente la tasa de éxito sube muchísimo cuando puedes dar pistas concretas de implementación. Esa es una parte que a un senior le resulta fácil porque conoce bien el codebase, pero puede ser difícil para un junior. Creo que hay que mirar todas las aristas. Hasta ahora, todavía suele ser apenas más rápido hacerlo yo mismo que ponerlo a correr con aider, pero la diferencia no es grande y sigue mejorando. Un LLM puede reemplazar algunas tareas que podría hacer un desarrollador junior, pero no puede reemplazarlo por completo. Un junior también va a reuniones, lidera discusiones y además tiene una ruta de crecimiento para terminar siendo senior. Pero desde la perspectiva de la gerencia, puede que eso no les importe.
La IA es una herramienta fantástica para consultar grandes volúmenes de información de manera difusa. Últimamente cada vez uso más Assistant de Kagi antes que una búsqueda normal. Me ayuda a encontrar la palabra que me faltaba, y luego con esa palabra termino encontrando lo que quiero al revisar páginas. Pero nunca he obtenido un valor realmente sostenido del vibe coding. Para trabajos one-off es excelente. Por ejemplo, al hacer gráficas en matplotlib, si le digo qué quiero y solo le muestro el esquema de datos, acierta como en un 90%. También arma shell scripts sencillos. Hace poco le pedí una herramienta CLI pequeña para organizar fotos RAW por carpetas usando información EXIF, y para ese tipo de cosas me deja muy satisfecho. Pero en cuanto le pides algo un poco más complejo, empieza a hacer muchas cosas inútiles. Duplica modelos que ya existen en el proyecto, hace cambios no relacionados o se inventa funciones de API que no existen. Para validar el resultado, mejor lo escribo yo mismo. Y además, para mí, el proceso de programar directamente es la parte más divertida. Todavía no he encontrado un caso en el que los LLM encajen bien con el flujo de uso real, donde un humano obtiene un resultado temporal vía prompts y de inmediato tiene que guardarlo, integrarlo y entregarlo.
La IA sí sirve muchísimo para filtrar rápido la respuesta que busco entre cientos de sitios desastrosos llenos de anuncios. Uso seguido Duck Duck Go AI para preguntas y respuestas. Le tengo la confianza justa como para lanzarle un centro de datos, pero es útil para información que se puede verificar rápido, como sintaxis de programas u opciones de comandos.
En el uso de IA aplica perfecto eso de “obtienes lo que metes”. Si inviertes mucho tiempo explicando el funcionamiento interno, edge cases, arquitectura, elección de librerías, etc., y lo documentas cuidadosamente en Markdown, después de unas pocas iteraciones es bastante probable que salga código utilizable. Hay una gran diferencia frente a prompts cortos como “hazme la función X”. Pero si ya puedes escribir un prompt tan bueno, en realidad ya resolviste casi todo el problema, y el LLM solo está actuando como un mecanógrafo automático rápido. Solo acelera la escritura; la mayor parte del pensamiento ya la hizo el humano.
Creo que al menos hay un CEO que sí entiende esta parte. La idea de saltarse a los juniors y llenar todo solo con IA le hace daño a una empresa a largo plazo. Si los seniors se independizan y se van, no queda nada. Sinceramente, no estoy seguro de que la IA realmente beneficie a ningún ingeniero, incluidos los juniors. La ingeniería de software es un proceso de exploración y aprendizaje. Cada vez que uso IA me acuerdo de mi profesor de matemáticas diciendo: “si usas calculadora, no se te queda nada en la cabeza”. En general, también me da la impresión de que la IA es un resultado natural de los últimos 45 años de política económica en Estados Unidos. Es puro impulso al resultado de corto plazo para beneficiar solo al 1%, de una forma que daña el desarrollo a largo plazo de un ecosistema empresarial y económico sano. Viendo esto, da la impresión de que Jack Welch estaría muy orgulloso.
En los últimos meses, trabajando con startups, he visto muchos casos de gente tan metida en el LLM vibe coding que ya no puede salir de ahí. A menudo no lograron contratar bien o dejaron ir a su talento técnico. Confunden el código de IA, especialmente el de Claude, con un ingeniero interno 10x y esperan iteraciones más rápidas y mejor código. He visto a fundadores bastante inteligentes volverse adictos a la dopamina que les produce sentir que el código de Claude hizo en días o semanas algo que parecería semanas o años de trabajo de ingeniería de software. Creer que la IA puede “pensar” o “entender” problemas complejos es darle demasiado crédito. Creo que deberíamos medir el “ahorro en velocidad de tecleo”, no la capacidad real de razonamiento. [1] vibebusters.com
Estoy completamente de acuerdo con eso de enseñar “cómo pensar” y “cómo descomponer problemas”. El mejor profesor que tuve en ingeniería siempre hacía exámenes open book. En el mundo real todos trabajan en un entorno donde pueden consultar todos los datos y toda la información. A la gente no se le paga por encontrar datos, sino por analizarlos, entenderlos y aplicarlos de forma lógica. A eso precisamente le llamamos ingeniería, y eso era exactamente lo que ese profesor enseñaba.
En la universidad llevé un curso de álgebra abstracta. Todos los exámenes consistían en escribir de memoria demostraciones famosas y en crear demostraciones nuevas. Memorizar por memorizar me parecía forzado, pero me di cuenta de que no podías memorizar una demostración sin entenderla. Y al crear una demostración nueva, ya tenías módulos mentales en la cabeza, así que podías abordarla de una manera mucho más intuitiva. La verdadera memorización no es lo mismo que memorizar código estilo problemas algorítmicos, y creo que programar aplicaciones reales se parece mucho más a una exploración improvisada de grafos, humana y basada en estado. Los problemas reales no vienen siempre con un orden nuevo ya dado; al final, lo clave son las heurísticas.
Creo que ese es el problema central al que se enfrenta la contratación en este campo. Un desarrollador realmente capaz es, en esencia, un generalista. La especialización sin duda tiene valor, pero salvo en situaciones como infiernos de código legacy o cuando hay que romper límites muy específicos, un especialista no siempre es indispensable. De hecho, alguien que ya trabajó con stacks desconocidos puede ayudarte a cubrir debilidades o aportar una mirada fresca. Un buen desarrollador generalista se adapta rápido a cualquier stack. Porque cada empresa usa una mezcla de tecnologías diferente y desordenada. Aunque pongas requisitos como “15 años de experiencia en React”, nadie que llegue va a tener productividad máxima desde el primer día. Siempre hace falta tiempo de onboarding. Pero la gente que contrata en el trabajo real no suele entender esto bien. Las grandes empresas al menos entrenaban a la gente, pero últimamente ya ni eso se siente como antes. Se gastan cientos de miles de dólares por la competencia de contratación, pero luego no piensan mucho en el costo real de formar y hacer crecer a alguien. A nivel de toda la industria, también ayudaría tener una asociación profesional que impidiera que toda la estructura de contratación y desarrollo de talento sea un desastre total, pero como no existe, el problema empeora. (Creo que por eso mismo hoy se habla más de sindicatos, con tanto recorte, outsourcing, etc.)
Da la impresión de que ese cambio ya está ocurriendo, ¿no? La mitad del currículo tradicional de CS es matemáticas, y la otra mitad básicamente también es matemáticas aunque con otros nombres. Se critica mucho a la academia, pero cuando alguien dice “la academia es tonta, deberían enseñar esto”, normalmente eso ya se está enseñando, o en todo caso es algo que se puede aprender rápido justo en la medida necesaria. La mayoría de las nuevas tendencias ya forman parte de lo que se hace.
En la universidad, el departamento de filosofía tenía el eslogan de marketing “la carrera de pensar, estudia pensamiento”. Por experiencia como reclutador, la gente que estudió humanidades suele ser mucho mejor en tareas esenciales como analizar y comprender. Yo también tengo sesgo porque hice doble carrera en CS y filosofía, pero de verdad un junior con capacidad de pensamiento analítico es mucho más valioso que alguien que solo sabe escribir mucho código. El pensamiento analítico es mucho más difícil de enseñar que programar.
En mi primer semestre tuve un profesor que llamaba “crazy finger syndrome” a esa tendencia de la élite de computación de querer ponerse a programar de inmediato sin descomponer primero el problema desde la perspectiva del negocio o del usuario. Extraño sus bromas sobre “los estudiantes ansiosos que solo quieren programar”. Creo que últimamente los bootcamps no siempre están alineados con estándares éticos altos.
Escuché la pregunta: “¿qué pasa en el futuro si ya no queda nadie bien formado?”. Creo que mucha gente ya está aceptando esa conclusión como algo obvio. Aun así, no veo fácil salir de una estructura donde la mayoría de las empresas se enfocan más en la rentabilidad de corto plazo que en la sostenibilidad a largo plazo. Por eso se sigue enfatizando tanto el internado/co-op como forma de mantener viva la tubería de talento. También espero una tendencia a apostar todavía más por internships para esquivar las dificultades de contratar desarrolladores junior.
Si resumo mi experiencia, se siente así: nuestro jefe hizo PR declarativo diciendo que iba a despedir a mucha gente por adoptar IA y aparentó ser un líder en IA, pero cuando lo intentaron fue un desastre total y ahora me toca a mí salir a pedir disculpas y dar explicaciones.
Jefe -> VP: "Hay que recortar gente por la IA" VP -> público: "En 2 años vamos a reemplazar a todos los ingenieros con IA" Jefe -> VP: "También hay que recortar VPs por la IA" VP -> público: "Reemplazar gente con IA es una estupidez"
Igual seguimos sin contratar desarrolladores junior.
Parece que el CEO de AWS también cambió de postura. Hace un año decía que “la IA va a estar programándolo todo en 2 años” [1]. Por fin parece que la c-suite está aceptando la realidad. [1] https://news.ycombinator.com/item?id=41462545
En realidad el CEO no dijo eso exactamente. Solo dijo que dentro de 2 años los desarrolladores podrían dejar de escribir casi todo el código. Y luego añadió: “ahora hay que enfocarse más en qué construir, cómo construirlo y qué necesitan realmente los clientes”. Link al artículo Hay una línea de contexto consistente desde la premisa hasta sus declaraciones actuales. “Escribir código” como tal podría volverse menos importante, y por eso hay que seguir contratando juniors para enseñarles cómo aprender y desarrollar capacidades realmente útiles.
En teoría, la mayor parte del valor de Amazon como empresa es la capacidad de su gente. Algunos ven al personal solo como un costo y sostienen que todo el valor pertenece a los accionistas. Pero si en verdad los activos humanos tienen valor, entonces decir que cualquiera puede obtener ese valor solo con IA en realidad perjudica la acción. Hasta existe riesgo de caída del PE, así que es raro interpretarlo de forma positiva. Si de verdad crees que con pura IA cualquiera puede hacer cualquier cosa, entonces para el accionista eso solo aumenta la carga de estar buscando constantemente el siguiente “nuevo motor de crecimiento”, en vez de poder mantener el capital apostado con estabilidad en empresas como las FAANG.
Para un ejecutivo, siempre es indispensable leer el momento histórico.
No es una postura contradictoria en absoluto. Para darle instrucciones a una IA autónoma necesitas una tubería de talento que se forme desde los juniors, no solo desde los seniors. Las grandes empresas se preocupan por esa tubería, y las compañías pequeñas pueden aprovechar eso para contratar solo seniors en el corto plazo y dejar de tomar interns.
No hay contradicción lógica entre ambas declaraciones. Puedes seguir contratando juniors aunque su trabajo termine siendo distinto del coding práctico.
Si parece que su postura difiere de la del jefe, recomendaría verificarlo directamente. No es buena práctica citar artículos de noticias sin contexto. Porque nadie puede predecir realmente el futuro. [1]: https://www.shrm.org/topics-tools/news/technology/ai-will-shrink-corporate-workforce--amazon-ceo-warns
No creo que las declaraciones de los dos CEOs entren en conflicto. “Tenemos que seguir contratando recién graduados universitarios y enseñarles la manera correcta de construir software” - Matt Garman “Se va a necesitar menos gente para varios de los trabajos que hoy hacemos” - Andy Jassy Solo cambia el matiz; en esencia es algo parecido.
Creo que, al citar, lo ético es reproducir siempre la fuente original con la mayor fidelidad posible y con contexto. A quién eliges citar y qué contexto construyes determina el tono de la noticia.
Ambas declaraciones son muy consistentes lógicamente.
Como alguien que ya salió de AWS, no confío del todo en los comunicados oficiales de AWS. Ya sabía qué tipo de empresa era AWS, y llegué ahí a mis 46 años como mi octavo trabajo. Incluso hubo puestos descritos como “remoto permanente” donde, después de que yo ya me había ido, de todos modos terminaron imponiendo una orden de regreso a oficina (RTO).
La tubería de talento en investigación académica funciona así: estudiante de licenciatura -> estudiante de posgrado -> postdoc -> tenure/senior. Salvo unas poquísimas excepciones, nadie se convierte en investigador senior saltándose esas dos primeras etapas. En cualquier industria pasa igual. Si no hay juniors, no puede haber seniors, así que si quieres que los “bots” hagan todo, también tienes que prepararte para ese riesgo.
Estoy seguro de que cualquiera que haya trabajado con estos modelos por mucho tiempo va a estar de acuerdo. Mirando en retrospectiva, el post de sama sobre AGI antes del lanzamiento de o3 y todo el doomposting tecnológico de ese momento fueron realmente absurdos.
El doomerism sobre AGI no era más que una estrategia de marketing. Ahora todos entienden cuál es la esencia de la IA, y lo que estamos viendo es otra repetición de un nuevo mercado de search donde la IA te lee todos los documentos.
Desde el principio era ruido tonto, pero nadie está totalmente libre del hype. Sobre todo porque se metió muchísimo dinero en inflar la percepción de la tecnología más allá de su realidad, haciendo astroturfing.
Considero que ChatGPT es mejor que cualquier desarrollador junior con el que he trabajado. Un junior es una carga neta para el equipo durante casi un año. Desde la perspectiva de alguien responsable de proyectos reales, jamás pensé “ojalá tuviera más juniors”. Mucho mejor pagar 20% más y atraer a alguien de nivel intermedio.