- La afirmación de que la IA multiplica por 10 a 100 la productividad de los ingenieros no es realista
- Al usar a fondo herramientas de IA para programar, la mejora de eficiencia es limitada y los picos temporales de productividad solo aparecen en tareas repetitivas y simples
- Los cuellos de botella del desarrollo de software (revisión de código, colaboración, planificación, etc.) no pueden superarse con IA, y es imposible lograr una mejora de 10x en todo el trabajo
- El mito del ingeniero 10x surge por diversas motivaciones, como distorsión de cifras, intereses de actores de la industria o generación de ansiedad dentro de las organizaciones
- Mantener tu propia forma de desarrollar y el disfrute del trabajo produce mejores resultados a largo plazo y una cultura organizacional más sana
Escepticismo ante el mito del ingeniero 10x con IA
Ansiedad por la productividad y experiencia real usando herramientas de IA
- En LinkedIn, Twitter y otras redes se ha expandido el discurso de que la IA aumenta de 10 a 100 veces la productividad de los ingenieros, y muchos desarrolladores sienten ansiedad por quedarse atrás
- El autor también probó en trabajo real varios agentes de generación de código con IA (Claude Code, Cursor, Roo Code, Zed, etc.), pero aunque eran cómodos para tareas simples y repetitivas, en trabajo complejo del mundo real no hubo una transformación fundamental
- En JavaScript (especialmente React), el código repetitivo (boilerplate) puede escribirse rápido
- Pero con estándares propios del codebase o librerías poco comunes, la IA no logra seguir bien el ritmo
- En lenguajes como Terraform, la IA no está tan familiarizada y su rendimiento baja
- Por el fenómeno de alucinación (hallucination), puede generar librerías que no existen y hasta provocar vulnerabilidades de seguridad
- La capacidad de la IA para entender el contexto sigue siendo limitada. Cuanto más complejo es el codebase real, más aparecen prompts repetidos, errores y pérdida de tiempo
- Como resultado, el autor usa la IA en scripts pequeños o tareas no críticas, y sigue haciendo directamente el trabajo complejo o importante
El problema de cuantificar la productividad en el desarrollo de software
- La afirmación de que la productividad puede subir 10x a 100x con IA está muy alejada de la realidad
- 10x o 100x de productividad no significa solo escribir más líneas de código, sino que algo que tarda 3 meses (desarrollo completo, revisión de código, QA, etc.) termine en 1.5 semanas
- En el desarrollo de software existen muchos cuellos de botella: planificación, estimación de story points, corrección de bugs, revisión de código, espera de despliegue, pruebas, QA
- Para que esa meta fuera posible, cada uno de esos procesos tendría que acelerarse 10 veces en la misma proporción
- En la práctica, el tiempo dedicado a programar es menor, y gran parte del tiempo se invierte en entender, diseñar, revisar y comunicar
- En términos reales, la revisión de código, la colaboración, la comunicación y el QA no pueden acortarse con IA
- El verdadero cuello de botella del trabajo de ingeniería está en las personas, los procesos y la comunicación
- Los LLM (modelos de lenguaje grandes) reducen el tiempo de teclear, pero el tiempo para calidad de código, pruebas y revisiones sigue siendo necesario
- Aunque la IA pueda aumentar temporalmente la velocidad de escritura de código, el aumento de errores, estándares deficientes y la necesidad de volver a promptear hacen que no tenga un impacto decisivo en la productividad total
- Una productividad 10x es, en la práctica, un objetivo casi imposible
La realidad y los límites del ingeniero 10x
- Sobre la existencia del "ingeniero 10x", el autor considera que puede darse de forma temporal y limitada
- La razón principal es la capacidad de prevenir trabajo innecesario (evitar desarrollo innecesario desde la etapa de planificación, mejorar la experiencia de desarrollo, documentar, etc.)
- Pero no todos los ingenieros se encuentran con esas situaciones todo el tiempo
- Un ingeniero excepcional puede prevenir trabajo innecesario o mejorar sistemas para elevar la eficiencia de toda la organización, pero en la práctica casi no existen casos de rendimiento 10x sostenido
- Las herramientas de programación con IA no contribuyen mucho a prevenir trabajo innecesario
- Incluso pueden llevar a sobreimplementar o proponer arquitecturas equivocadas por recomendaciones de la IA
- Programar más rápido no siempre significa ser un mejor ingeniero
El contexto y las motivaciones detrás del mito del 10x con IA
La mayoría de las afirmaciones sobre "productividad 10x" provienen de factores como los siguientes
- Ingenieros bienintencionados que cometen errores de medición
- Con herramientas de IA es posible tener por momentos una experiencia explosiva de eficiencia (ej.: escribir automáticamente reglas personalizadas de ESLint)
- Pero cuando ese tipo de trabajo se repite, la diferencia de productividad termina reduciéndose drásticamente
- La novedad técnica y la adaptación a un entorno nuevo pueden generar al principio una percepción exagerada de eficiencia
- Incentivos e interesados
- Fundadores de startups de IA, inversionistas y otros actores suelen citar cifras exageradas por razones de éxito comercial
- También ingenieros o ejecutivos pueden mencionar productividad inflada para responder a expectativas dentro de la organización
- Objetivos malintencionados
- Algunos directivos difunden afirmaciones exageradas con la intención de generar ansiedad en los ingenieros y frenar salidas, pedidos de aumento u otras sacudidas internas
- El miedo de que cualquiera pueda ser reemplazado fácilmente por la IA se repite periódicamente (similar a debates pasados sobre bootcamps de programación)
Resultados reales de la IA en open source y proyectos prácticos
- La mayoría de los casos reales sobre mejoras de productividad con IA muestran distancia entre quien escribe sobre ello y el ingeniero cuya productividad supuestamente mejoró.
- Los casos en que el propio ingeniero demuestra directamente el uso de herramientas de IA muestran una realidad más sobria y menos exagerada
- Los resultados del uso de IA en proyectos open source muchas veces aparecen por debajo de lo esperado o incluso como casos de fracaso
- En demos públicas o casos reales de ingeniería, la IA a veces puede parecer magia, pero en la mayoría de los casos no es muy distinta de un simple "generador de texto"
Un valor más importante que la "productividad": mantener una forma de desarrollar que vaya contigo
- A veces la IA permite escribir código más rápido, pero el autor sigue valorando más el disfrute de programar en sí
- Si no te gusta programar con IA o no te resulta disfrutable, está bien renunciar a una parte de la productividad
- Incluso aceptando cierto grado de ineficiencia, trabajar de la manera que mejor se adapte a ti produce mejores resultados y una vida laboral más sana a largo plazo
- Cuando se trabaja con disfrute, se logra mejor resolución de problemas, diseño y colaboración con colegas
- El disfrute y la inmersión importan más para la productividad y la calidad del código a largo plazo, y perseguir la productividad a la fuerza aumenta el riesgo de burnout
- En cambio, si programar con IA realmente te divierte y te ayuda, también está bien aprovecharlo activamente
Consejos para una cultura organizacional sana
- Al introducir herramientas de IA, generar expectativas irreales y ansiedad en todos los ingenieros perjudica la productividad de la organización
- La obsesión con maximizar productividad lleva a baja de calidad, deterioro del codebase y pérdidas a largo plazo
- Lo deseable es dar a los ingenieros suficiente autonomía y confianza, y permitir que cada quien elija cómo usar la IA de la forma que mejor le funcione
- La organización puede ofrecer oportunidades para usar IA, pero es importante mantener un ambiente que garantice autonomía
- Si los LLM y la innovación en programación con IA realmente dieran una productividad 10x, los desarrolladores lo descubrirían por sí mismos de forma natural
Conclusión
- La revolución del ingeniero 10x gracias a la IA está más cerca del mito y no existe una receta secreta que realmente se esté pasando por alto
- Lo más importante es confiar en tu propia capacidad y en tu forma de trabajar
- Las redes sociales (especialmente LinkedIn y Twitter) amplifican mitos exagerados, así que se pueden ignorar sin problema
10 comentarios
¿De verdad había gente que interpretaba 10x como literalmente diez veces? Obviamente pensé que era una expresión exagerada de marketing/autopromoción, así que me desconcierta que se lo tomen tan en serio.
Aunque no llegue a ser 10x, hay bastantes organizaciones que tienen una convicción seria sobre el Nx. Esperan reemplazar costos laborales por costos de IA y obtener resultados aún mayores... Eso no es una ilusión sin fundamento, porque cuando un PM quiere probar algo como un PoC sencillo o una herramienta para tareas repetitivas, se arma rapidísimo. Entonces, ¿hay desarrolladores que crean en esto...? Yo diría que, según la situación en la que cada quien se encuentre, el ambiente de la industria está lo bastante cargado como para generar una sensación real de ansiedad. Creo que este tipo de discusión seria también es necesaria, aunque sea para poder comunicarse con personal no técnico y con líderes de la organización.
Por supuesto, no estoy negando que ayude a la productividad. (Con el nivel actual de la IA, en este momento) me parece obvio que eso de 10x no tiene sentido, pero como el contenido del post original iba explícitamente de decir que “no llega a 10x”, escribí este comentario porque eso me resultó bastante desconcertante; aunque sí creo que la forma de expresarlo no fue muy buena.
Así como dices que la productividad de la IA es una exageración usada para marketing o autopromoción, creo que ese artículo también incluye algo de exageración.
Por eso, eso de preguntar si realmente hubo gente que interpretó 10x como literalmente 10 veces da un poco la impresión de estar buscándole el pelo al huevo, así que quizá por eso generó rechazo.
Parece que respondiste sin leer el texto original; en ninguna parte del original se puso tan solemne, la verdad...
Entonces, el uso "decenas de veces" mayor frente a Viewtrap de DataTube.tv, la herramienta para encontrar ideas virales de YouTube que desarrolló el autor, también será por supuesto una expresión exagerada para marketing/autopromoción, ¿no?
No sé si será por ser en línea o si simplemente así eres normalmente, pero la mayoría de tus comentarios estaban escritos desde una mirada crítica. Ojalá lo vieras con una perspectiva un poco más abierta.
Creo que así como existe mucho revuelo con la IA, también existe el extremo contrario, así que no tengo grandes opiniones sobre el texto en sí...
Este comentario me da cosa, la verdad; da miedo que hasta busquen publicaciones pasadas antes de volver a comentar, sobre todo si recién te registraste hoy
Viendo el comentario que dejaste y aun revisando mi historial, no creo que haya ni un solo comentario del que de verdad deba avergonzarme. ¿El problema es mirar las cosas desde una perspectiva crítica? ¿Se vive mejor no dejando ningún comentario en absoluto, como tú...?
¿Eh? Incluso ya había convertido esa cifra de 10x a meses... Entiendo si te molestó la expresión de que me lo estaba tomando demasiado en serio. Varias decenas de veces lo de Datatube es una cifra cuantitativa. Bueno, de todos modos no es que lo esté operando ahora mismo, pero...
Opinión de Hacker News
No entiendo por qué solo en ingeniería de software existe esta obsesión con el mito de la productividad "10x"; en ingeniería mecánica, eléctrica, civil o química no existe ese concepto
Un gran ingeniero es alguien capaz de reducir riesgos y diseñar sistemas dentro de diversas restricciones
Diseñar es el proceso de entender un dominio mediante modelos y comprender el rango de validez y los límites de esos modelos
No existe el "10x", solo existe hacerse responsable de buenos sistemas
Si existiera un ingeniero de software "10x", sería alguien que evita incidentes como filtraciones de datos, y más bien me gustaría ver que ese tipo de incidentes se redujera 10 veces
Yo también coincido con gran parte de este texto
Soy muy fan del desarrollo con herramientas de IA, pero las afirmaciones de productividad 10x nunca me parecieron convincentes
Gracias a los LLM, algunas tareas como teclear código se volvieron entre 2 y 5 veces más rápidas, pero eso es solo una parte del trabajo total
De hecho, muchos ingenieros creen que ciertas tareas pueden acelerarse entre 20 y 50%, pero coinciden en que eso no se traduce en un aumento del 20% en la productividad total ni mucho menos en 10x
Claro, alguien que use IA realmente bien puede sentir una mejora mayor que 0.2x, pero por la complejidad intrínseca del desarrollo de software, 10x es irrealista en la mayoría de los casos
Cuando uso IA tengo que estar vigilándola todo el tiempo, así que no siento que sea tan eficiente
A veces las sugerencias de copilot coinciden perfectamente con lo que estaba pensando y me sorprenden, pero en general no se siente como un desarrollador junior muy competente sino como un "desarrollador senior borracho" que no hace mucho caso
La mitad del código generado ni siquiera compila, y aunque compile, no funciona bien
En mi experiencia, la IA no da un aumento enorme de productividad en trabajo de creación, pero sí ayuda mucho en exploración, aprendizaje, destrabar bloqueos y escribir código repetitivo
Pero el verdadero cambio ocurre en los proyectos paralelos
Antes estaba demasiado cansado como para dedicar tiempo a proyectos extra, pero ahora, aunque el código no sea perfecto, puedo convertir ideas en algo real rápido y con mucho menos esfuerzo mental
También puedo experimentar libremente con habilidades de ingeniería de IA sin restricciones de fechas límite, privacidad o herramientas
Incluso la gente a la que llaman "ingenieros 10x" probablemente verá una mejora mínima de productividad con IA
Los mejores desarrolladores que conozco destacan por dos capacidades: una memoria descomunal y conocimiento detallado de todos los lenguajes y bibliotecas, y una creatividad y capacidad de resolver problemas casi milagrosas
Me impresiona que, aunque no conozcan fórmulas o teoría, llegan a la solución más original y elegante para el problema
Si haces pair programming con IA, para llegar a una solución similar la IA necesita intentos e iteraciones infinitas, y más bien termina ralentizando al genio humano
Pero como el espectro de capacidades es tan amplio, en mi caso sí puede haber una mejora de productividad de 10x gracias a la IA
Mi formación no es en software y, como soy perfeccionista, desarrollo muy lento, así que la IA me sirve para hacer rápido una primera versión horrible y probar ideas
Yo también estoy a favor de desarrollar asistentes de IA y creo que en algunas situaciones puede haber mejoras de velocidad de 2x a 10x
Pero la mayoría de las veces eso de productividad "10x" se usa de forma exagerada para decir que todo el proceso de desarrollo de una funcionalidad, de principio a fin, se volvió 10 veces más rápido
En la realidad, muchas partes del proceso completo de desarrollo, aparte de programar, no se aceleran 10 veces
Aun así, en entornos realmente pequeños o donde trabajas solo, sí te puedes saltar muchos procesos engorrosos, así que el aumento real de velocidad puede ser grande
En ese contexto, estamos entrando en una época donde los equipos pequeños y el desarrollo individual de pronto se vuelven competitivos
Gracias por el comentario de Simon
Este sí da la sensación de que realmente leyó el texto
Reconozco que en algunos trabajos especializados en cierto lenguaje o herramienta sí se están dando mejoras reales de productividad de 2x
Durante décadas soñé con automatizar el desarrollo de software, y siento que los LLM hicieron realidad ese sueño de una forma completamente distinta
Las herramientas CASE, UML, IDE y similares prometían "dejarte concentrarte en la lógica real", pero los LLM simplemente generan código ejecutable directamente a partir de lenguaje natural
Muchos desarrolladores sienten que se derrumbaron los antiguos ritos de paso y tienen miedo de quedarse atrás en este nuevo mundo, una especie de síndrome del impostor
Ahora nos volvemos a preguntar qué significa realmente la ingeniería de software
Los LLM son la forma definitiva de aquellas viejas herramientas CASE, pero todo ocurrió demasiado rápido y de forma confusa y disruptiva
Ahora incluso gente que no conoce el "lenguaje sagrado" del ingeniero de software tiene poder, y muchos ingenieros se ven obligados a preguntarse "¿qué estoy haciendo ahora mismo?"
Recién ahora entiendo cómo se sintieron los artistas cuando vieron stable diffusion
El código generado por IA al final suele estar mal, lleno de bugs, convenciones raras y cosas inútiles
Arreglar todo eso puede tomar tanto tiempo como hacerlo uno mismo
Aunque pruebes distintos modelos o afines los prompts, da la sensación de que ese código de alta calidad que realmente quieres todavía no está al alcance
Igual que con stable diffusion, alguien que no presta atención quizá no note que algo está raro; del mismo modo, alguien que no sabe de código generado por IA puede no darse cuenta de que tiene problemas
Hace poco revisé el código de un compañero de trabajo porque se veía raro, y estaba lleno de problemas, ni siquiera se podía depurar, y al final admitió que "solo programó por intuición"
Al ver el mundo reciente, siento que el capital sigue destruyendo el trabajo
Bajos salarios, malas condiciones laborales, vigilancia, presión por métricas, empresas poco éticas, contratos cortos: la realidad de la mayoría de los trabajadores se sigue deteriorando
Nosotros habíamos estado demasiado protegidos como para sentirlo de verdad, pero ahora también estamos frente a un futuro inestable
La "ingeniería de software" al final se convertirá en trabajo de arreglar vibes
Muchos trabajos pueden sustituirse por software, pero ya existía la realidad de que, si los gerentes no podían demostrar valor comprobable, no querían contratar SWE
Con la adopción de IA, los gerentes van a generar montones de código que no entienden, y cuando dentro de 3 años todo se rompa, volverán a llamar a SWE para arreglarlo
De hecho, es muy posible que aumenten más los trabajos difíciles y de alto valor dedicados a arreglar "problemas que la IA no puede resolver"
Los LLM crean código directamente sin modelos formales ni diagramas
Yo más bien quisiera que la IA generara esos diseños formales o diagramas
Ese tipo de herramientas ayudaría a entender el código y aclarar el diseño
Ojalá la IA también diera soporte en esa parte
El cuello de botella en el desarrollo de software no es la velocidad de tecleo ni la generación, sino la verificación y la comprensión
Aunque un LLM funcionara perfectamente y sin alucinaciones, un desarrollador responsable tendría que revisar el código línea por línea
Como un humano no puede entender código 10 veces más rápido, en la práctica puede tomar incluso más tiempo repasar el código autogenerado y descifrar intenciones ocultas
Hablar de "productividad 10x" solo aplica cuando se entrega la salida sin validar o cuando se trata de código muy simple donde los errores no importan
En software de producción, donde un error puede ser un desastre, el cuello de botella sigue siendo la capacidad cognitiva humana; como los LLM solo trasladaron la carga de escribir a revisar, incluso pueden restar productividad total
Esta discusión se siente como si desarrolladores promedio estuvieran revelando su propia productividad
Si entiendes la tecnología del proyecto y sabes dividir bien el trabajo, puedes anticipar la complejidad del código y pedirle a la IA que trabaje en unidades adecuadas
La IA no es magia; tiene un límite de complejidad que puede manejar
Si entiendes bien ese límite y la tecnología del proyecto que estás construyendo, puedes dividir los componentes por debajo de ese umbral y darle instrucciones a la IA
Ese enfoque funciona bastante bien
Eso es casi una tautología
Si simplificas las instrucciones para que la IA funcione bien, obviamente va a funcionar bien
Pero en la práctica hay que darle indicaciones demasiado detalladas y aun así no puedes confiar en el resultado sin revisarlo a fondo
De hecho, desmenuzar tanto el trabajo para explicárselo a la IA puede ser más engorroso que escribir el código directamente
Si la IA acierta de una sola vez, sí hay eficiencia, pero en la realidad muchas veces terminas corrigiendo una y otra vez o rehaciendo todo, desperdiciando tiempo y esfuerzo
El código estructurado y bonito de la IA suele estar mal en la práctica, y eso es peligroso
La parte realmente difícil y lenta es diseñar las partes complejas
Las partes triviales solo requieren entrada, pero resolver las partes complejas es lo que realmente consume tiempo
Se percibe un tono de "¿yo me considero un desarrollador por encima del promedio?" detrás de este comentario
También podría ser al revés
Mientras desarrolladores poco competentes se maravillan con resultados generados por IA y envían PR automáticos sin sentido, quienes tienen estándares altos quizá no se impresionen con esos resultados
En realidad es difícil distinguir en quién se puede confiar sin haber trabajado directamente con esa persona, así que me mantengo neutral
Tanto la IA como los humanos tienen límites
Al final, lo que se necesita es la aburrida gestión de proyectos
Si tienes buenos requisitos, diseño adecuado y suficiente información, y lo divides en tareas pequeñas, hasta puedes decirle a la IA "implementa el issue #42 de GitHub" y verla trabajar mientras ves TV
Pero si le dices "hazme Facebook", obviamente todo saldrá mal
Otra área donde la IA me ayudó muchísimo es encontrar bugs
Trabajo sobre todo con simulaciones numéricas, y un problema que me tuvo bloqueado varios días —un error de escala en una ecuación causado por unos paréntesis faltantes— lo resolvió rápidamente chatgpt cuando le expliqué el archivo y el síntoma
A veces la IA sirve para señalar con claridad lo que yo pasé por alto
Eso no te convierte en un desarrollador 10x, pero si la usas bien, sí se siente un efecto muy positivo
A mí me pasa igual
Generar código con IA es más o menos regular, pero para depurar sí representa un salto enorme de productividad
Es como una especie de "rubber duck" superinteligente
(Desde la perspectiva de un desarrollador aficionado) Gracias a los LLM, programar se volvió mucho más fácil cuando ya es tarde en la noche y mi cabeza no da para más
Yo también he ahorrado muchísimo tiempo gracias a la IA
Para mí se siente como algo entre 10x e infinito
No creo ser un ingeniero 10x
La razón por la que soy más productivo que mis compañeros es que diseño sistemas y no sigo los tickets ambiguos del negocio tal como vienen
Si la IA no logra simplificar el trabajo de mis colegas es porque ellos no cambian su hábito de complicarlo todo desde el principio
La IA no resuelve ese problema
Como en mi empresa mi sueldo no es el doble del de mis compañeros, así lo veo
Adoptar herramientas de IA no va a cambiar esa realidad
Este texto establece primero un estándar demasiado alto con eso de "10x", y luego registra el intento personal del autor por superarlo
Por eso creo que divide a los partidarios de la IA en tres grupos: quienes se engañan, quienes venden, y gerentes oportunistas que explotan la ansiedad ajena
Personalmente, considero que quejarse de las "alucinaciones" es un poco una "señal"
Creo que hablar de alucinaciones es totalmente necesario
La discusión sobre LLM se ha ido a extremos demasiado marcados: o no sirven para nada, o van a reemplazar a los desarrolladores
Por ejemplo, Claude 4 Sonnet respondió incorrectamente que Godbolt estaba equivocado sobre algo relacionado con compilación en clang
Aun así, en general esta sesión me ayudó mucho, así que solo hay que recordar que debemos ser críticos con los resultados
Las alucinaciones sí existen y siempre hay que mantener cautela frente a la salida
Gracias por dejar el comentario, y tus textos sobre IA me ayudaron a superar el síndrome del impostor
En el texto solo estaba clasificando a quienes afirman haber logrado repetidamente el "10x", no metiendo a todos los partidarios de la IA en el mismo saco
Me da curiosidad saber si encontraste algún método sin alucinaciones
Sobre todo en Terraform y similares, el LLM sigue inventando propiedades inexistentes, y en JS también se confunde mucho cuando usas bibliotecas poco comunes
Si quejarse de las "alucinaciones" es una señal, entonces pensar eso también es una señal…
(réplica breve)
Ese estándar 10x es marketing exagerado común en toda la industria
Ejemplos: la afirmación 10x de Sam Altman
la promoción de productividad de Cursor AI
desarrolladores 10x aumentados por IA
Supongamos que alguien que no sabe hacer una web app apenas logra construir una después de estudiar 4 horas al día durante 6 semanas, en total 120 horas
En cambio, si usa IA como Claude code y hace la misma web app en dos días de fin de semana, 12 horas, entonces la productividad subió 10 veces
Eso se parece bastante a algo que sí me pasó a mí
Antes no hacía ciertas cosas por falta de motivación o energía, pero con IA ahora sí puedo lograrlas en un fin de semana
Pero el primer método incluye aprendizaje, así que puede ayudar cuando quieras cambiar algo la próxima vez
En realidad, si le pides a una IA como Claude Code que te haga scaffolding de una web app fuera de React, el resultado puede ser un desastre
Alguien sin experiencia desarrollando apps no va a crear fácilmente una aplicación pulida en un fin de semana
Incluso el primer login de usuario puede romper todo de inmediato
A largo plazo, creo que esa aritmética no tiene sentido
Con LLM al principio haces la app rápido, pero poco a poco tu capacidad de mantenimiento cae, y llega un momento en que ya no puedes meter ni gestionar el sistema, que se fue complicando, dentro de la "ventana de contexto"
Como resultado, la productividad puede terminar acercándose a cero
Básicamente externalizaste por completo el cerebro y la experiencia de aprendizaje, así que apareció una app, pero casi no hubo crecimiento ni aprendizaje
¿Piensas desplegar eso directamente?
En la práctica no están en el mismo plano
Ya es difícil medir el resultado de un desarrollador 1x, así que multiplicarlo es todavía más absurdo
Siento que la IA aumenta muchísimo la "productividad de side quests"
La IA es ideal para esas cosas que uno viene posponiendo por flojera, como hacer mockups, escribir tests, extraer bibliotecas o documentar
Aunque no reduzca el tiempo para crear una funcionalidad, si incluyes esas tareas complementarias el resultado se acerca un poco más a estar completo
Ojalá que ese trabajo adicional luego reduzca el tiempo necesario para encontrar bugs
(Experiencia personal)
Esto aplica solo a mi caso, pero en mi empresa es común que el código de tests hecho con LLM quede demasiado acoplado al código de implementación
Se abusa mucho de patrones como test spies
Como resultado, terminamos con muchos tests ambiguos que revisan detalles internos de implementación en vez del comportamiento desde la perspectiva del usuario
Esos tests se rompen demasiado seguido cuando cambia la implementación, así que en vez de ayudar a la productividad terminan siendo una carga
No es solo culpa de los LLM; más bien el problema es que desarrolladores que ya de por sí no sabían escribir buenos tests empeoran con LLM
En desarrolladores con poca experiencia en TDD o en tests bien diseñados, los LLM amplifican esos antipatrones
Me gusta la expresión "productividad de side quests"
La IA no se siente como "mil cortes de muerte", sino como "una nueva vida hecha de mil curitas"
Coincido con el concepto de "side quests"
En realidad, el gran cambio es que gracias a la IA ahora puedo crear herramientas o funciones que sin IA ni siquiera habría hecho
No se trata solo de ahorrar dos semanas, sino de que apareció un resultado que antes no existía
Las expectativas sobre los LLM están por encima de la realidad, pero en la práctica son muy útiles en situaciones diversas
Si lo ves por niveles de zoom, los resultados fueron mucho mejores cuanto más descomponía el trabajo, desde algo tosco como "vibe coding" hasta pedir "hazme esta función"
Además de generar código, también son eficaces para aprender nuevas tecnologías y otros usos
Si mi rol tiene muchas reuniones o mucho trabajo gerencial, la ayuda de los LLM disminuye
Creo que en el futuro también podrán aprovecharse en flujos de trabajo de PR, limpieza de commits y reorganización del orden de trabajo
De hecho, incluso si se usa solo para refutar a los ingenieros que suelen decir a ciegas "no se puede" o "es inviable", parece que igual tendría un efecto X10.
Lo digo porque he visto muchas veces esa escena de tratar a quienes no desarrollan como ignorantes y decir que algo no se puede sí o sí.