En Amazon, algunos desarrolladores dicen que su trabajo ha empezado a parecerse al trabajo de almacén

• Los desarrolladores de Amazon están experimentando presión por la velocidad de trabajo y simplificación de tareas tras la adopción de IA
• Los gerentes están recomendando fuertemente el uso de herramientas de IA con el argumento de mejorar la productividad
• Algunos creen que, al reducirse las tareas repetitivas, la calidad del trabajo ha mejorado, pero también existe la preocupación de que los desarrolladores junior pierdan oportunidades de crecimiento
• A medida que programar pasa de ser una creación directa a un trabajo centrado en revisar y verificar, algunos sienten que ya no parece su propio trabajo
• Grupos internos como Amazon Employees for Climate Justice están compartiendo estrés laboral y ansiedad sobre el futuro, incluyendo este problema

---

At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work

La programación también entra en la era de la carrera por la velocidad

• El fenómeno de simplificación del trabajo por la mecanización, que se ha repetido desde la Revolución Industrial, también está ocurriendo en el campo de la programación
• La IA, más que eliminar empleos, está transformando los puestos existentes en una forma de trabajo más simple y rápida
• Según una investigación de Microsoft, la productividad de los desarrolladores que usaron el asistente de IA ‘Copilot’ mejoró en más de 25%
• Amazon ha adoptado esto y está exigiendo trabajar más rápido y con mayor eficiencia mediante IA, destacándolo en su carta a los accionistas como clave para la ‘reducción de costos y el mantenimiento de la competitividad’
• Por ejemplo, un equipo de desarrollo está operando con la mitad del tamaño del año pasado y aun así se le exige la misma cantidad de código

Una tendencia en toda la industria

• Shopify estableció el uso de IA como requisito básico para todos los empleados y especificó que también se reflejará en la evaluación de desempeño
• Google está usando sus hackatones internos con el tema de desarrollar herramientas de IA para elevar la productividad cotidiana. Ya más del 30% del código se genera a partir de sugerencias de IA

Aspectos positivos y preocupaciones

• Algunos gerentes sostienen que, con la adopción de IA, se reducen las tareas aburridas y repetitivas y se puede enfocar más en trabajo creativo
• Amazon mencionó que, gracias a la IA, ha ahorrado el equivalente a 4,500 años de trabajo de desarrollo
• Sin embargo, el economista de Harvard Lawrence Katz señala que para los desarrolladores principiantes esto elimina oportunidades de crecimiento profesional
• De forma similar a la ‘carrera por la velocidad’ que vivieron antes los obreros de fábrica, los desarrolladores también están siendo presionados para procesar más y más rápido

Los cambios que sienten los desarrolladores

• Al igual que en los centros logísticos de Amazon, los desarrolladores también perciben automatización y división del trabajo impulsadas por la IA
• El uso de IA es ‘opcional’, pero en la práctica se vuelve indispensable para cumplir las metas de desempeño
• Funcionalidades cuya implementación antes tomaba varias semanas ahora deben terminarse en cuestión de días, y para ello se reducen las horas de reunión y se amplía el uso de código generado por IA
• La IA incluso puede generar programas completos, pero aumenta el trabajo de leer y revisar código, y disminuyen la diversión y el nivel de involucramiento

Menor crecimiento profesional y menor involucramiento

• Los desarrolladores junior podrían perder la oportunidad de entender el código a profundidad debido a la automatización de pruebas
• La IA apoya diversas tareas, como redactar documentos de planificación y probar código, pero el entorno está cambiando hacia una evaluación centrada en herramientas, no en personas
• Harper Reed, ex CTO de la campaña de Obama, considera que ha llegado una era en la que no es necesario entender a profundidad cada parte, y explica que se trata de un cambio similar al de la manufactura
• En cambio, Simon Willison valora positivamente la IA porque acelera la materialización de ideas

Quejas y respuesta organizacional

• Debido al uso de IA y a los cambios laborales que esto trae, muchos desarrolladores están compartiendo ansiedad y estrés en el grupo Amazon Employees for Climate Justice
• En particular, hay mucha preocupación por el deterioro de la calidad del trabajo y la incertidumbre profesional, algo similar al estrés de la carrera por la velocidad que sentían antes los trabajadores automotrices
• Aún no hay un movimiento para formar un sindicato de desarrolladores, pero el consenso interno dentro de la organización sigue creciendo

Contexto histórico y perspectivas futuras

• Como en la huelga de GM de 1936, los problemas relacionados con la velocidad del trabajo y la autonomía pueden convertirse en un catalizador de acción laboral
• Antes, las personas podían ajustar su forma y ritmo de trabajo, pero ahora se está pasando a un sistema donde todo el proceso es monitoreado y evaluado con foco en la velocidad

[GN⁺]

Comentarios de Hacker News

• Contenido compartido del enlace de archive.ph/HVZRL
• A mí el desarrollo basado en LLM me parece una moda exagerada, como cripto o VR. Hace poco me tocó corregir bugs en una base de código escrita con vibe coding, y sentí que este enfoque es una especie de masa caótica donde problemas de negocio sin sistema se trasladan al código sin estructura. Como las partes que necesitan mejora se van parchando con arreglos estrechos, el resultado termina siendo código complejo y desorganizado. Cuando se topa con los límites de la context window, el LLM ni siquiera recuerda sus propios parches. El inglés (o el lenguaje humano) es ambiguo para describir con precisión el código que quiero, y volcar en prompts toda la suma de experiencia y ensayo y error que un desarrollador senior deja incorporada en el código es una tarea extremadamente pesada. A diferencia de responder "por qué se hizo así", aquí hace falta una lista enorme, específica e interminable de "en esta situación no hagas esto, haz aquello".
  • Es una observación que encaja perfectamente con cómo describiría la mayoría de las bases de código que he visto en los últimos 30 años, salvo una sola excepción.
  • Contraargumento: la IA también me ayudó a encontrar patrones de código en unas 30 partes donde había que extraer estructura. Creo que el problema del vibe coding es la actitud. Quien intenta evitar programar directamente tiende a enfocarse solo en la comodidad inmediata, por encima de la estructura o la calidad a largo plazo; en cierto sentido, es un amplificador de la pereza.
  • En realidad, mucho código de producción es un conjunto de fragmentos que funcionan a punta de parches. La triste realidad es que los CPU son tan rápidos que incluso ese código simplemente corre.
  • Coincido con la crítica de que el lenguaje humano no es claro. Al final, ya se ha intentado varias veces manejar software con claridad usando lenguaje natural, y como en el derecho, nunca dejan de aparecer zonas grises de interpretación. Si en el futuro los desarrolladores tienen que discutir el significado del programa antes de compilar, ese futuro será sombrío.
  • Sí parece que la IA está tan sobrevalorada como cripto o VR. Pero incluso en profesiones altamente técnicas como la ingeniería de software, la automatización terminará impactando. En los últimos 10 años, la gente del sector tech se engañó pensando que los problemas de otros trabajadores no tenían que ver con ellos, pero con la cultura de recortes y despidos ya empezó de lleno la contención salarial. Aunque la IA no sustituya a todos de inmediato, si un trabajo que hacían 5 personas ahora lo hacen 4 con IA, despiden a 1 y quienes se quedan tampoco se atreven a pedir aumentos. El argumento es que la gente de tech también tiene que darse cuenta de que, al final, son trabajadores.
• Sobre la opinión de Harper Reed de que “no hace falta entender el código a profundidad”, ese tipo de comentario se siente más bien como una lógica improvisada de “si compila, despleguémoslo”. En una línea automatizada se mide la calidad constantemente, pero las máquinas reales no alucinan con el ángulo ni hacen soldaduras absurdas; el software basado en LLM sí repite este tipo de errores pequeños.
• Queda la duda de si las herramientas basadas en LLM de verdad aumentaron drásticamente la productividad de los desarrolladores, o si las organizaciones solo descubrieron que pueden arreglárselas con menos desarrolladores —y menos privilegiados que antes—. Tampoco se ven muchos casos de “incremento revolucionario de productividad” dentro de las grandes tecnológicas, y hasta ahora apenas parece haber una mejora modesta, suficiente para compensar la inversión.
  • En gran parte es una cuestión de percepción. Antes el desarrollo era visto como algo difícil, pero con la llegada de las herramientas de IA se percibe que la barrera de entrada para programar bajó. El desarrollo de software se siente cada vez más como trabajo de fábrica, con menos recompensa intelectual.
  • Hay dudas sobre la mantenibilidad a largo plazo de la base de código. El vibe coding va acumulando gradualmente complejidad, bugs sutiles y problemas de abstracción, lo que al final vuelve más difícil el mantenimiento y el desarrollo de nuevas funciones. Se corre el riesgo de quedar atrapados en una productividad de corto plazo a cambio de una caída de calidad a largo plazo.
  • Las organizaciones siempre han intentado “salirse de la técnica” mediante procesos burocráticos, es decir, reemplazar gente más especializada por personal menos capacitado pero estandarizado. Puede ser una estrategia venenosa a largo plazo, pero mientras haya consistencia, se conforman con una “solución mediocre pero utilizable”.
  • Para que esa lógica sea convincente, habría que asumir que la dirección de Amazon prioriza más la ganancia de corto plazo que la calidad de largo plazo, y no estoy seguro de eso.
• Desde la perspectiva de alguien que está por jubilarse, los cambios recientes resultan desalentadores. Cuando empecé mi carrera en los 90, había tiempo para experimentar y sumergirse en la creatividad durante largos periodos. Hoy son obligatorias las tareas fragmentadas, los reportes de estado y la justificación constante. Seguirá habiendo desarrolladores interesantes, pero esas oportunidades se están reduciendo. En realidad, estamos recorriendo el mismo camino que otros trabajos cuya vida se volvió más dura por la automatización, así que es un resultado justo.
  • Los reportes rutinarios de estado, como el stand-up, toman tiempo y al final solo son una respuesta formal para ganarme un día más de libertad frente a gente que no entiende mi trabajo; degradan el valor del trabajo.
  • Yo también entré en los 90 y me identifico con este control minucioso basado en JIRA. Aun así, no creo que el pasado haya sido automáticamente una edad dorada. También hay un sesgo nostálgico de recordar solo las experiencias buenas. Pero incluso hoy hay trabajo desafiante, bueno y del que se puede aprender bastante.
  • Más que automatizar puestos de ingeniería, en realidad parece una dirección hacia reemplazar cargos gerenciales por supervisión centrada en IA.
• Para acelerar radicalmente el desarrollo de software, también existe el método de copiar tal cual el código open source de alguien, borrar rastros de copyright/licencia y aplicarlo. Si te preocupa que te descubran directamente, puedes usar un proveedor externo para “lavarlo”, o ahora incluso la IA puede lavarlo barato y rápido. Antes Google se contenía un poco más con este tipo de comportamiento y le faltaba audacia. Pero las startups pequeñas buscan triunfar rápido usando IA sin hacer mucho caso al riesgo de infringir copyright.
  • En la industria en la que trabajo, el problema más grande no es la falta de código, sino definir “qué hacer y cómo hacerlo”. Hay muchos problemas específicos que no se resuelven con Stackoverflow o Github.
  • En realidad Google ya venía raspando contenido de sitios para mostrarlo directamente en los resultados de búsqueda, aprovechando contenido ajeno sin enviar tráfico. Esta vez simplemente llegó tarde.
  • Irónicamente, algunos opinan que preferirían que una gran empresa al menos plagiara código open source, porque desde la perspectiva del usuario eso sería mejor que verse obligado a usar los métodos fríos e ineficientes que esas empresas construyen por su cuenta.
  • Coincido con los límites de subir código a open source. Las grandes empresas tienden a fomentar el open source como una forma de conseguir trabajo gratuito. Aunque a corto plazo bajen las contribuciones, a largo plazo eso podría hacer más sana a la industria.
  • Se señala la irresponsabilidad en torno a la aparición de ChatGPT y al liderazgo de Sam Altman.
• Me llamó la atención el comentario de Simon Willison de que leer código es más difícil y menos divertido que escribirlo, y el caso de un desarrollador de Amazon que dice que la IA le ayuda mucho con tareas secundarias como documentación y testing. Ahora el rol parece estar cambiando del coding a revisar código existente y corregir bugs.
  • Me acordé de cuando al principio era divertido escribir código. Ahora corregir bugs me resulta más entretenido, y el LLM se encarga del coding repetitivo simple, así que puedo concentrarme en retos más interesantes. Gracias al LLM, al menos sobrevive parte de la diversión del desarrollo.
  • El ambiente que transmite este texto es bastante negativo.
• Cuando aparece una nueva tecnología de productividad, las empresas se apresuran a capturar sus beneficios y estandarizarla. Para seguir el ritmo hay que estudiar sin parar, y en algún momento también conviene considerar pasar a un entorno donde uno capture directamente sus propias ganancias de crecimiento, como trabajar por cuenta propia. Pero trabajar solo significa competir con gente experta en IA, así que no hay una solución fácil.
  • Veo tres escenarios futuros. 1) Las bases de código se hunden cada vez más en el caos y la inestabilidad, y al final quizá haya que volver a contratar desarrolladores con experiencia a precios altos. 2) La IA produce código más o menos utilizable; la calidad y la confiabilidad son bajas, pero no ocurre ningún desastre grande. 3) La IA se vuelve repentinamente mucho más inteligente, desaparece la idea misma de base de código y entramos en una era de software generado y evolucionado dinámicamente según se necesite. Los LLM actuales están muy lejos de eso. Los ejecutivos creen en el escenario 3, pero por ahora la realidad está entre el 1 y el 2. Si se gestiona bien, también se puede avanzar hacia una visión equilibrada del escenario 2.
  • También existen modelos donde las mejoras de productividad se distribuyen de forma más justa. Como en la Europa de antes, con reducción de jornada laboral y cosas así. Hoy incluso los trabajadores parecen ocupados en tareas raras y difíciles de identificar solo para aparentar que están ocupados.
  • En realidad estás expresando una perspectiva prácticamente marxista, y es curioso que aun así la conclusión termine en alienación individual. Con un poco de organización conjunta sería posible mejorar las cosas, pero no se hace.
  • No aceptes sin más que hay que vivir en un ciclo interminable de autoformación; también existe la opción de unirse con otros miembros de la sociedad y exigir cosas colectivamente a los empleadores. La semana laboral de 5 días, la jornada de 8 horas y la prohibición del trabajo infantil se consiguieron mediante acción colectiva. No hace falta limitarse a trabajar duro en lo propio y enfocarse solo en que a otros les vaya bien.
• Siempre me sorprende cómo nuestra industria se va volviendo infantil. Quienes tienen experiencia en grandes empresas y grandes bases de código saben que generar código nuevo es solo una parte pequeña del desarrollo.
  • De hecho, fuera del código nuevo también hay muchas otras partes auxiliares ineficientes en las grandes empresas. La expectativa es que la IA cambie eso también y reduzca reuniones interminables o discusiones abstractas.
  • Mucha de la gente entusiasmada en este momento en realidad son personas para quienes escribir código se volvió difícil por estar atados a paradigmas recientes. Con herramientas LLM como Copilot arman rápido un POC y lo empujan hasta producción sin pensar mucho en calidad, escalabilidad y demás. Luego son ellos mismos quienes anuncian sin matices los supuestos aumentos de productividad por la IA, repitiendo argumentos alineados con los intereses de las grandes empresas. Pero cualquiera que la use de verdad en el trabajo sabe que también tiene muchas carencias.
  • Yo también paso apenas un 20% del tiempo programando; el resto se va en levantar requisitos, diseñar, probar y gestionar tiempos. Si ese 20% de trabajo de código se redujera a la mitad, probablemente podría usar el tiempo sobrante en testing o documentación.
• Existe la ilusión de que con ayuda de LLM la eficiencia del desarrollo aumentará enormemente. En realidad, solo cuando ya existe una base sólida se puede subir la productividad sin perder calidad. Es decir, funciona como amplificador de productividad para personas con experiencia, pero si le das LLM a un ejército de principiantes inflado en tamaño, será difícil obtener software de buena calidad.
  • Ese argumento se repite mucho, pero lo importante es dónde está la línea de corte de “calidad”. En la práctica, un equipo joven de estudio de desarrollo que conozco usa LLM de manera activa con revisión semanal de un amigo SRE, y la calidad y escalabilidad del código son suficientemente buenas. Van lentos, pero el resultado no es malo.
  • Solo algunos lugares necesitan software “bueno”; si uno mira cómo ganan dinero firmas como Deloitte o Accenture, queda claro que a la mayoría de las empresas ni siquiera les importa la calidad. Para la mayoría basta con software “más o menos convincente”.