- Han pasado unos 2 años desde el lanzamiento de las herramientas de asistencia de programación basadas en LLM
- Algunos desarrolladores reportan que su productividad aumentó hasta entre 5 y 10 veces
- Sin embargo, no hay evidencia clara de que la productividad de toda la industria del software haya aumentado entre 5 y 10 veces
- En la práctica, las herramientas con LLM se vuelven complicadas en tareas que van más allá de agregar funciones simples y repetitivas al código base
- La mayoría de los programadores no sabe cómo usar de forma efectiva las herramientas con LLM o no tiene interés en hacerlo
Por qué el aumento de productividad parece concentrarse solo en ciertos usuarios
- Si la productividad realmente aumentó entre 5 y 10 veces, es muy probable que eso esté limitado a un pequeño grupo de usuarios avanzados o desarrolladores experimentados que saben manejar bien los LLM
- No hay señales de que toda la industria del software esté entregando de golpe muchas más funciones útiles ni de una mejora claramente visible en la calidad
- El autor dice que en los últimos 1 o 2 años casi no ha percibido el impacto de los LLM
¿Qué proyectos han sido realmente posibles gracias a los LLM?
- No está claro qué proyectos se habilitaron específicamente gracias al desempeño de los LLM
- Incluso en la investigación casi no aparecen casos concretos de este tipo (el refactor de COBOL es prácticamente el único ejemplo)
- Los productos basados en LLM de los laboratorios de AGI tampoco muestran resultados particularmente impresionantes
- Se quedan en funciones básicas como subir PDFs a una ventana de chat
- Carecen de capacidades para que el LLM se integre con fluidez con distintos tipos de software y datos
Pregunta: ¿hay áreas donde la productividad realmente haya aumentado?
- No hay evidencia clara sobre qué proyectos se lanzaron más rápido gracias a los LLM
- No se ven señales de que algún sector específico del ecosistema de software haya crecido 10 veces
Lo que se quiere es evidencia práctica y concreta
- No hacen falta datos del siguiente tipo
- Afirmaciones vagas sobre una mejora de productividad de 10 veces
- Referencias a indicadores económicos abstractos o al aumento en la cantidad de código producido
- Casos simples de generación de herramientas o funciones basadas en LLM
- Ejemplos menores como "hacer un clon de Snake con ChatGPT"
Teoría conspirativa: la posibilidad de que los LLM no estén aumentando la productividad real
- Se termina gastando tiempo corrigiendo y resolviendo problemas en el código generado por LLM
- Cuando un código base grande generado por LLM supera cierto nivel de complejidad, puede volverse imposible de modificar y terminar requiriendo reescribirse desde cero
- Incluso si los LLM crean software nuevo, es muy probable que la mayoría sean herramientas de un solo uso o código de demostración que nunca se usa
- Aunque aumente la cantidad de código en software realmente útil, existe el riesgo de que también aumenten las funciones innecesarias o el
bloatware
- Existe la posibilidad de que los programadores estén siendo engañados por la experiencia casi “mágica” de obtener resultados inmediatos con LLM
Rango realista de mejora de productividad
- Según la experiencia del autor, los LLM solo son útiles en casos específicos como estos
- Escribir funciones pequeñas
- Ayudar a aprender una librería o un código base específico
- Realizar tareas simples de refactorización
- Es probable que la mejora de productividad esté más o menos en el rango de 10% a 30%
- Parece difícil lograr una maximización real de la productividad antes de la llegada de la AGI (inteligencia artificial general)
[Comentario de Richard Horvath]
Casos en los que un LLM puede ofrecer una mejora de velocidad de 10 veces en situaciones concretas
- Escritura de scripts pequeños e independientes
- Muestra grandes resultados al escribir tareas simples, por ejemplo scripts de
bash para manipular archivos o código VBA de Excel
- Se puede generar fácilmente con una descripción breve y además es fácil de verificar
- Se puede escribir incluso sin un conocimiento profundo del lenguaje
- No hace falta considerar mantenimiento, modularización ni pruebas unitarias
- Es especialmente efectivo en tareas relacionadas con expresiones regulares (
regex)
- Aumento de la velocidad de aprendizaje al trabajar con un stack desconocido
- Permite identificar rápidamente clases y métodos de una nueva librería
- Aunque el código no funcione por completo, ofrece una forma de abordar la resolución del problema
- Reduce de manera importante el tiempo que antes se iba en buscar documentación o tutoriales
- Sin embargo, el código generado necesita corrección y refactorización manual
Los tipos de personas que probablemente reportan un aumento de productividad de 10 veces
- Personas con poco conocimiento de desarrollo
- Si tienen habilidades básicas de programación insuficientes, el código hecho con ayuda de un LLM puede parecer muchísimo mejor que antes
- Pero en estos casos es muy probable que ese código termine teniendo efectos negativos a largo plazo
- Personas que necesitan escribir muchas soluciones pequeñas e independientes
- Tareas como automatización en Excel o escritura de scripts de shell en DevOps son especialmente favorables para los LLM
- Personas que deben experimentar con frecuencia con distintos stacks y librerías
- Esto aplica más a trabajos orientados a la experimentación que a trabajar a largo plazo en un stack específico
- Efecto de anclaje (Anchoring Effect)
- Cuando el LLM muestra resultados inmediatos en una tarea concreta, es fácil sobreestimar eso como una mejora sostenida de productividad a largo plazo
[Comentario de Davidmanheim]
- Desde la perspectiva de quienes programan en una empresa común y de la gerencia, es inevitable que la mejora de productividad por LLM sea en realidad limitada
- Esto se explica desde la teoría de restricciones (Theory of Constraints):
- Supongamos que antes el trabajo se completaba con un proceso como este:
- Analista de negocio (Business Analyst) → 1 día
- QA tester → 1 día
- Programador → 1 día
- Aunque la productividad del programador aumente 2 o 5 veces, el tiempo total del trabajo no se reduce
- Como las otras etapas (análisis de negocio y QA) se convierten en cuello de botella, la velocidad total del proceso se mantiene igual
- Hace falta rediseñar los procesos empresariales
- Para aprovechar al máximo la mejora de productividad por LLM, hay que reestructurar el proceso completo de la empresa
- Pero por ahora ese tipo de rediseño apenas está empezando en algunas compañías
[Comentario de faul_sname]
- Con LLM tuvo resultados especialmente notables en la generación de mockups de UI:
- Antes, crear mockups de UI representaba cerca del 10% del tiempo total de trabajo
- Gracias a los LLM, la velocidad para generar mockups de UI aumentó unas 5 veces
- Pero eso no significa que el tiempo total de trabajo haya disminuido
- En cambio, mejoraron mucho el detalle y la interactividad de los mockups de UI
- También fue posible hacer más iteraciones, lo que terminó mejorando la calidad del producto
- Que un “código desechable” exista no significa necesariamente que sea inútil
- Incluso un prototipo o código de prueba puede contribuir a desarrollar un mejor producto final
- Además, los LLM dan respuestas sobre errores específicos que son difíciles de encontrar en buscadores
- Ejemplo: "cómo resolver un error que ocurre en una tarea ejecutándose en el stack xyz"
- Ayudan a depurar en situaciones concretas de stack y configuración de Kubernetes
- Evalúa el aumento total de productividad en alrededor de 10% a 30%
- Pero la productividad no mejoró de manera uniforme en todas las tareas
- Mejoras drásticas de velocidad en tareas específicas (por ejemplo, mockups de UI o debugging)
- Sin resultados particularmente relevantes en trabajo complejo o con código legacy
- La mejora de productividad destaca al inicio del proyecto, pero su efecto disminuye en fases complejas de mantenimiento
- Por eso, considera que el límite aquí no es la falta de agency, sino un problema de gestión de contexto (context management)
[Comentario de Noosphere89]
- Citando la postura de Ajeya Cotra, menciona los siguientes puntos sobre el efecto de los LLM en la productividad de los programadores:
- La productividad de la AI en tareas de programación es mayor de lo esperado
- La AI está logrando resultados importantes en tareas de programación
- Pero en tareas fuera de la programación su rendimiento cae bastante
- Por eso, su impacto industrial total sigue siendo limitado
- Enlaces a comentarios relacionados de Ajeya Cotra
- Sobre la afirmación de que “para lograr resultados de largo plazo hace falta AGI”:
- En la trayectoria actual de avance de la AI, la capacidad general (Generality) es menor de lo esperado
- Es común que el rendimiento de la AI mejore de golpe en ciertas tareas o muestre debilidades en áreas específicas
- Debido a este desequilibrio de capacidades, el concepto de AGI (inteligencia artificial general) podría ser menos útil de lo que se esperaba
[Comentario de yo-cuddles]
- El ejemplo de una persona en su oficina que se dedica a automatización robótica de procesos (RPA)
- Él insiste con mucha convicción en que es mucho más productivo
- Pero en la práctica su trabajo es ineficiente y poco confiable, y otras personas pierden tiempo corrigiéndolo
- Sus colegas intentan dejarlo fuera del flujo de trabajo
- Las personas no miden bien su propia productividad y tienden a notar solo ciertos logros o pérdidas:
- Se concentran en los logros visibles
- Cuando terminan rápido una tarea con un método automatizado, la sensación inmediata de logro es grande
- Como el resultado rápido se ve enseguida, se percibe como un efecto positivo
- Los costos de largo plazo son difíciles de percibir
- El costo en tiempo que aparece después del trabajo no se rastrea fácilmente
- Sobre todo si otra persona corrige el problema, ese costo casi no se nota
- Aunque se corrijan errores surgidos en tareas automatizadas, es difícil sentir el tiempo perdido que eso causó
- Los problemas causados por código generado por LLM son difíciles de reconocer por razones como estas:
- Es difícil rastrear con precisión que la causa de un bug fue código generado por LLM
- Otra persona puede terminar perdiendo tiempo adicional en el proceso de arreglar el problema
- Puede que ni siquiera se identifique la causa raíz del problema ni que se note que surgió por usar una herramienta de automatización
- La sensación de “terminé más rápido gracias a la automatización” es fuerte, pero “el tiempo desperdiciado por culpa de la automatización” es mucho más difícil de percibir
- Aunque el uso de LLM ya se volvió común, no se ve con claridad un aumento de productividad en toda la industria
- La gente dice que es “2 veces más productiva”, pero en realidad es muy posible que la productividad haya empeorado por problemas ocultos
- Es decir, como el tiempo y los recursos gastados en resolver esos problemas no son visibles, se termina inflando la percepción del resultado
6 comentarios
Se parece mucho a mi propia experiencia.
En casos como estos, sí me ahorró bastante tiempo. Muchas veces tampoco se encuentra bien con la combinación de Google + Stack Overflow, y en Stack Overflow en particular, aunque haya una respuesta, siempre hay muchos comentarios objetándola o diciendo que es una forma de implementación de una versión antigua y que ya no debería usarse, así que eso me resultaba bastante molesto...
Parece que la productividad de 10x aparece cuando se está haciendo prototipado.
A mí me resulta bastante agradable.
> La mayoría de los programadores no sabe cómo usar eficazmente las herramientas de LLM o no le interesa.
A muchos desarrolladores a su alrededor, sorprendentemente, no les interesa mucho la tecnología. Dedican la mayor parte de su tiempo a consumir de forma mecánica shorts de YouTube nuevos o repetitivos.
Opiniones de Hacker News
Trabajo en una empresa tecnológica popular de Seattle y nos están obligando a usar IA. La dirección está rastreando cuánto usan la IA los desarrolladores, e incluso me preguntaron personalmente por qué no la uso más. Creo que es importante usar la herramienta adecuada para la tarea adecuada, y la IA no siempre encaja
Hay un viejo dicho en los proyectos de software: el último 10% toma el 90% del tiempo. La IA es útil en el primer 90%, pero no ayuda en el último 10%
En FAANG usamos LLM integrados en el IDE, y el efecto ha sido algo positivo
Como ejemplo de un desarrollador que realmente experimentó una mejora de 10x, está el caso de Pieter Levels, que programó un simulador de vuelo multijugador 3D en pocos días
Intenté usar LLM para generar código, pero al principio mi productividad bajó
Soy parte del equipo que desarrolla Copilot Autofix en GitHub, que ofrece sugerencias de corrección basadas en alertas de CodeQL
La calidad de las respuestas de los asistentes de codificación con LLM depende mucho de la capacidad de comunicación del programador
La suposición de que la productividad del software no ha mejorado entre 5x y 10x podría ser incorrecta
Parece que el último punto de la traducción del resumen de opiniones de Hacker News, «podría ser incorrecta la suposición de que la productividad del software no ha mejorado entre 5 y 10 veces», es una mala traducción. Viendo el texto original, un resumen más razonable sería algo como: «decir que la productividad del software mejoró entre 5 y 10 veces se basa en una suposición equivocada sobre la mejora de la productividad».