- El debate actual sobre los LLM se está dando sin una base cuantitativa clara.
- La experiencia de cada usuario es muy fragmentaria, y casi nunca se comparten elementos clave como el entorno real de uso o el conocimiento de contexto.
- Debido a su naturaleza no determinista, incluso una misma tarea puede arrojar resultados distintos en distintos momentos, lo que limita su confiabilidad.
- Las afirmaciones exageradas de líderes de la industria están alentando una aceptación acrítica y expectativas excesivas.
- En la práctica, el autor también usa a diario diversas herramientas de IA, y comparte la experiencia real de que solo obtiene el resultado deseado aproximadamente la mitad de las veces.
El debate en torno a los LLM y la visión sobre esta tecnología
Críticas a los LLM y el ambiente que los rodea
- En el debate reciente sobre la IA, en especial sobre los LLM (modelos de lenguaje de gran escala), se ha formado un ambiente donde las posturas críticas suelen ser descartadas como “opiniones de personas que no entienden bien la tecnología”.
- En Hacker News y otros espacios, se repite la reacción de que “si le haces preguntas a la IA es porque no entiendes la esencia del tema”.
La brecha entre las experiencias de los usuarios
- Sobre la utilidad real de los LLM, existe una diferencia de opiniones entre quienes dicen “sí ayudan hasta cierto punto” y quienes afirman “probé de todo y no sirven de mucho”.
- La razón de esta diferencia es que no se comparten criterios ni información concreta sobre esas experiencias.
- En qué tipo de proyecto se usaron
- El estado de la base de código (proyecto nuevo, código maduro, código fuente privado, etc.)
- La experiencia del usuario y qué tan conectada está esa experiencia con el problema real
- El esfuerzo adicional que hizo falta para realmente pulir y desplegar el resultado generado por el LLM, entre otros detalles que no suelen darse
La dificultad de comparar experiencias y el no determinismo
- Incluso si una persona compartiera toda la información en detalle, comparar experiencias con las de otro usuario sería casi imposible.
- Los LLM y los agentes de automatización son, por naturaleza, no deterministas.
- Aunque se les pida lo mismo de la misma manera para el mismo problema, cada vez se obtienen resultados distintos.
- Hay demasiadas variables que cambian, como el tipo de proyecto, el modelo usado, las herramientas o el lenguaje, lo que dificulta una validación consistente.
Líderes de la industria y expectativas exageradas
- Hay muchos casos en los que líderes de la industria exageran los logros de los LLM.
- Ejemplo: un líder del sector contó que con “Claude Code” logró corregir un bug antiguo con una facilidad sorprendente, y obtuvo una gran respuesta pública sin compartir detalles.
- Se difunde únicamente un mensaje muy positivo, omitiendo información clave como el tamaño del código, la dificultad del bug, si hubo trabajo adicional, o qué lenguaje y framework se usaron.
- Casos así acumulan más de 1.8 mil reacciones y 204 republicaciones, lo que facilita la propagación de un marketing exagerado.
La experiencia de uso y la percepción de la realidad
- El autor también utiliza todos los días diversas herramientas de IA como v0 de Vercel, Claude Code y Midjourney.
- Creó una app de monitoreo en SwiftUI sin tener conocimientos de Swift.
- Generó automáticamente pósters para eventos con Midjourney.
- También tiene experiencia programando funciones de servidor MCP basadas en Elixir.
- Pero la probabilidad de éxito es de alrededor del 50%, y los resultados nunca son completamente consistentes.
- A veces los LLM pueden sentirse como magia, pero en realidad no son más que modelos estadísticos no deterministas.
- El autor señala que, en esta realidad, el debate de la industria sigue atrapado en una dicotomía (magia vs. ingeniería).
Conclusión
- El panorama en torno a los LLM y la IA tiende a favorecer imaginaciones exageradas, expectativas y creencias, sin un sistema de verificación firme y claro.
- Es importante no dejar de lado el pensamiento crítico y seguir intentando verificar en detalle las funciones y efectos reales.
- Lo importante en estas discusiones es compartir información concreta y cuantitativa.
- Hace falta una mirada equilibrada sobre los límites y las posibilidades de los LLM.
1 comentarios
Opinión de Hacker News
Me frustra escuchar a la gerencia donde trabajo hablar de aumentos de productividad de 10x. Algunos incluso lo repiten porque los early adopters de mi empresa lo dicen directamente. Pero esa expectativa es demasiado alta. La ley de Amdahl también influye: la mayor parte de mi tiempo no la paso programando, sino pensando y comunicándome. Aunque programar realmente fuera 10x más rápido (que en la mayoría de los casos no lo es), la productividad total solo mejoraría entre 10% y 15%. Aun así sería un resultado bastante bueno, pero no 10x
Quizá porque mi trabajo actual se parece más a I+D, pero los LLM me dan una ganancia tan grande en la parte de “pensar” como en la de “programar” (la comunicación la resuelvo bien por mi cuenta). Usar LLM para pensar se siente parecido a cuando dominé la búsqueda web hace 20 años. Antes con los buscadores tenía que saber qué estaba buscando, pero ahora el LLM primero encuentra qué debería buscar (y hasta lo busca por mí). Tareas que antes clasificaba como difíciles ahora se resuelven fácilmente gracias a los LLM. En este momento hago alrededor de un tercio de mis búsquedas web con ChatGPT o3. Ya no me imagino renunciando a eso. Además está el componente psicológico de que el LLM ordena mis ideas incompletas y actúa como interlocutor de debate. Gracias a eso muchas cosas se sienten mucho menos intimidantes, y esa diferencia también es grande
En mi empresa pasa algo parecido. Los aumentos de productividad que afirman los early adopters internos suelen medirse de una forma muy estrecha, o directamente las cuentas están medio flojas
Puede que los LLM aceleren más a un desarrollador senior que a uno junior (porque un junior no distingue tan bien entre código bueno y malo). Si un senior usa un flujo de trabajo mejorado con LLM, quizá logre una productividad equivalente a la de diez juniors de antes. Incluso un mal desarrollador puede volver la productividad efectivamente negativa (porque consume el tiempo del senior). Y hasta un junior decente termina en tareas repetitivas que el LLM ya hace mejor. Por eso sí creo que algunos trabajos podrían desaparecer de verdad
Si usar herramientas LLM solo aumenta la productividad 10%~15%, pero el costo de contratar sube 10%~15% por pagar esas herramientas, entonces no veo una ventaja especial. Hay que considerar el costo total de producción
En proyectos personales sí es fácil ir casi 10x más rápido. Pero en una empresa ese entorno no encaja por las conversaciones entre varios equipos, los cambios de requisitos, las revisiones de PR, etc. Ese tipo de diseño optimizado y patrones estándar solo son posibles en startups pequeñas o proyectos individuales. En cuanto se junta más gente, ponerse de acuerdo ya es difícil. Para que la IA dé el mejor resultado, todo tendría que estar estandarizado, pero en la realidad siempre hay pequeñas desviaciones, así que en una organización real cuesta ver ese nivel de impacto. Entre unos pocos desarrolladores muy alineados quizá sí se pueda llegar a 10x, pero en un entorno corporativo es casi imposible. Me parece que la IA encaja mejor en gestión media y planeación de proyectos
Yo soy del lado que el autor del post está criticando. Lancé un producto greenfield en la época en que ChatGPT todavía era bastante limitado. Después usé Claude y el flujo de copiar y pegar entre web chat y XCode, y luego Cursor. Había errores de compilación a menudo, pero aun así mi productividad subió al menos 3x. Ahora que los agentes funcionan mejor y salió Claude 4, casi no programo. Actúo como Architect/Manager y solo dirijo bien a los agentes con mi conocimiento experto. Llevo meses en una startup sin escribir ni una sola línea de código directamente. Reviso todo antes de abrir un PR yo mismo, y pruebo todo a fondo, pero la combinación Cursor+Sonnet está fuera de serie. El número de líneas no importa, y de hecho expertos del codebase legado con muchos años encima me preguntan a mí por bugs menores. Gracias a Claude hasta me he metido con trabajo de frontend, así que ando con cuidado. No se trata solo de lanzar queries, sino de hacerlo pasar por investigación minuciosa, planeación y exploración paso a paso. El conocimiento del dominio sigue siendo indispensable. Aun así, me sorprende que haya gente que no pueda usarlo así de bien. Siento que veo dos artículos como este cada semana
Mi experiencia también es parecida, aunque en un entorno algo distinto (soy estudiante de PhD). Era escéptico con los LLM, pero después de Claude Code mi forma de trabajar cambió por completo. Aun así, la curaduría sigue siendo totalmente mi responsabilidad (una soft skill importante que se aprende en el doctorado, y además porque los LLM pierden rápido el objetivo o el contexto, o no lo recuerdan). Si puedes comunicarte con precisión, con CC puedes organizar el cómputo de formas que antes eran imposibles. No es que programar se vuelva más fácil, sino que aparece un formato completamente distinto
Me da curiosidad cuál es el proceso real de validación e inspección: cómo revisan rápido código LLM en el que no se puede confiar, si el LLM también escribe unit tests, cuál es la longitud promedio de los prompts, etc.
Señalan si de verdad se confía de inmediato en la salida del LLM. Como el LLM no logra captar el contexto completo del proyecto y alucina mucho, hace falta validarlo
Siento que la calidad del código generado por LLM sigue siendo bastante deficiente en general. Como requiere varias rondas de corrección, muchas veces es más rápido escribirlo yo mismo. Pero para refactorizaciones mecánicas a gran escala, los agentes sí son muy útiles. En vez de armar macros complejas de vim o scripts con AST, uso agentes
Personalmente, eso de pasar meses sin escribir una sola línea de código me parecería demasiado aburrido
Básicamente vuelve a confirmar lo que decía el blog post (afirmaciones difíciles de verificar, promesas enormes, etc.). Además, parece una cuenta recién creada
Yo creo que en realidad gran parte del trabajo del sector servicios consiste en tareas manuales tipo mover datos entre hojas de Excel o entre CRM, email y Excel. En las grandes empresas debe haber cien veces más empleados de tiempo completo haciendo ese trabajo repetitivo que ingenieros de software. Así que no importa si el LLM no sabe OCaml; si en Excel lo hace apenas un poco mejor que un humano, ya crea un valor enorme. Si conectas email-CRM-Excel con algo como MCP y automatizas, también baja muchísimo la tasa de error o de alucinaciones. Los humanos también son no deterministas, así que en estos procesos el determinismo no es lo importante. LLM y criptomonedas son totalmente distintos en utilidad y adopción. A mí esto me recuerda a la expansión de los smartphones. Mis amigos no técnicos ahora usan LLM para muchísimas cosas
No creo que la comparación con las criptomonedas sea constructiva. Técnicamente no tienen nada que ver. Pero sí existe ese fenómeno de sobreestimar una tecnología. Para alguien que ni siquiera ha tenido contacto con automatización básica, el LLM puede parecer ciencia ficción. Nunca antes este campo había sido tan mainstream. De aquí en adelante será una especie de Lejano Oeste con éxitos, fracasos, opiniones diversas y experiencia real mezcladas. Lo bueno es que ahora hasta la idea de una app de un amigo ya se puede experimentar directamente
Los FTE (Full-time Employee) que limpian datos manualmente también tienen la responsabilidad de validar resultados, cumplir plazos y asumir responsabilidad legal. El LLM no puede detectar fuera de contexto excepciones temporales (por ejemplo, que en un feriado un valor debería ser 0) para revisarlas. Solo por esa validación ya puede valer completamente la pena tener a un FTE
Me pregunto en qué tipo de empresa hay 100 FTE haciendo trabajo manual de canalización de datos por cada ingeniero de software. No creo que la mayoría del trabajo real de back office o data entry sea así. Estoy de acuerdo con el impacto de la IA, pero soy escéptico ante la idea de que casi todo el trabajo de oficina sea básicamente email + captura de datos
Creo que se está subestimando la complejidad de este tipo de puestos
Hablo como programador retirado, y no me imagino dejando una responsabilidad mission-critical en código generado probabilísticamente. Puedo entender usarlo si con unos ajustes queda utilizable. Fuera de la programación (brainstorming, pensamiento creativo, apoyo en investigación), los LLM me parecen sorprendentes. Yo los trato como compañeros de pensamiento. Cometen errores, pero es fácil detectarlos si se validan con otras fuentes o si otro LLM los revisa
Yo también soy escéptico por naturaleza, pero al usarlo en la práctica superó mis expectativas en todos los sentidos. En unas horas avancé desde prototipo hasta lanzamiento en proyectos que me habrían tomado meses. Las cosas que sí puedo hacer ahora las hago más rápido, y hasta cosas que no podía hacer (y que habría tenido que subcontratar o contratar a alguien para hacer) las resuelvo por un costo mínimo y muy rápido. Claro, no es perfecto y tiene cosas irritantes (ignorar instrucciones explícitas, mentir, etc.), pero para mí sí cambió el juego
Usar LLM como compañero de pensamiento me funcionó un rato, pero en algún momento sentí que se revelaba la fantasía. Los LLM te hacen creer muy bien que saben o razonan. En especial es más peligroso en áreas que yo no conozco. En un buscador puedes comparar confiabilidad entre fuentes, pero con un LLM eso no pasa. Y detectar errores tampoco siempre es fácil
Soy desarrollador con 40 años de experiencia y empecé a usar LLM hace unos meses; mi manera de trabajar cambió mucho. Pego mensajes de error de logs y obtengo una corrección en un minuto, hago brainstorming de diseño, recibo propuestas de soluciones nuevas, etc. Sí valido el código, pero me sorprenden todos los días su precisión e inteligencia. (No tiene nada que ver con las criptomonedas)
Aunque soy escéptico de los LLM, en realidad todo código escrito por humanos también es esencialmente probabilístico. Por eso existen code review, unit tests, pair programming y guías. Ni la salida de un LLM ni la de una persona se deben usar sin juicio crítico. Solo me preocupa que, como los LLM no son magia, se terminen usando mal para inflar boilerplate ignorando valores de largo plazo como eficiencia, seguridad o refactorización, fuera de las áreas donde sí ayudan
En mi opinión, donde mejor rinden los LLM es en data science. El IO está claro, así que es fácil validar los resultados. Si conoces las características de ciertos datos, también puedes hacer que generen test code fácilmente. Cuando hace falta contexto, Claude Code cambia mucho las cosas. Como ejemplo: extraer múltiples mensajes dentro de cada paquete UDP de un archivo PCAP, filtrarlos, hacer pattern matching y separarlos para pruebas. Si le dices “escríbeme unit tests para todas estas funciones”, el LLM hasta puede auto-validarse
Llevo casi un año usando LLM casi todos los días, y en 90% de los casos me resuelven el problema. No sé cuándo debería tomar realmente en serio las opiniones negativas sobre AI/LLM. En mi experiencia nunca se trató de meter todo el codebase y esperar magia; solo hago preguntas precisas y específicas sobre cosas que conozco y entiendo, y aplico la solución de forma que pueda validarse. Si no se usan así, entonces se están usando mal. Para vivir la “magia” de verdad, la clave es un uso pequeño, cotidiano y consistente
Como en una parodia del hombre del clima: “funciona siempre con 60% de probabilidad”. Yo también uso GPT y Claude a diario con Cursor. GPT o3 sirve bien para buscar conocimiento general, y Claude a veces falla. El modelo en sí es medio tonto, pero a veces sí da justo en el blanco. Creo que se puede usar productivamente si uno mismo sabe lo que quiere y sabe domesticar bien al LLM
También hay quien dice que le cuesta creer esa afirmación de “en mi experiencia funciona bien el 90% de las veces”
El autor parece estar enojado con comentarios inexactos de opinadores. Pero en realidad, quienes más conocen los problemas y límites de los LLM son justamente los usuarios-promotores que chocan con ellos todos los días. Problemas que antes eran imposibles o casi imposibles, como traducción, transcripción o generación de código (hasta cierta escala), ahora están resueltos total o casi totalmente
¿De verdad la traducción, la transcripción y la generación de código eran casi imposibles? Señalan que Google Translate, Whisper, etc. existen desde hace tiempo
Quienes exhiben defectos reales son los detractors (críticos), mientras que los promoters (entusiastas) más bien elevan a los LLM sin crítica, como si sirvieran para todo
Últimamente siento que el uso de términos como AGI y AI, sobre todo en artículos científicos, es demasiado ambiguo. Al menos me gustaría que cada paper dejara clara su propia definición. Si se define con precisión qué es AGI, entonces hasta se podría demostrar lógicamente si cierta IA cumple esa definición. Aunque no pareciera tener mucha utilidad práctica, sería mucho mejor que usar términos vacíos. Ahora se siente como si usaran AGI sin definirlo para poder escaparse. En Wikipedia aparece algo como “casi todas las tareas cognitivas al nivel humano o por encima”, pero eso no se puede medir. Me pregunto por qué usar un término tan hueco
Tampoco hace falta que todos lo usen con exactamente el mismo significado. Basta con que cada quien tenga su propio criterio para la palabra AGI (aunque la mayoría no esté de acuerdo). Para mí crypto originalmente significa cryptography. Lo que usa la corriente principal y mi criterio personal pueden ser distintos
Si AI tiene una definición, sería “todo lo que todavía no se ha logrado” según la explicación del AI effect
En mi empresa recién empezamos a usar LLM. La primera tarea fue transcribir 20 mil llamadas de atención al cliente y extraer datos (productos comparados, problemas, casos de uso representativos, etc.). Una investigación que antes habría tardado semanas se hizo en unas horas. Incluso armamos una nueva estrategia de negocio y realmente obtuvimos mucho valor. Como motor de procesamiento de lenguaje natural, el LLM es excelente. Hay mucho marketing exagerado, pero para nosotros sí fue de ayuda concreta. Al final es solo una herramienta, y no siento necesidad de demostrarle nada a nadie
Creo que la exageración no es inocua. También distorsiona el mercado, impulsa sobreinversión, recortes organizacionales y expectativas irreales, entre otros efectos negativos. Hace falta que existan artículos así para enfriar un poco el mercado y las expectativas. Quienes venden LLM normalmente no hablan de resumir llamadas de soporte, sino de todo tipo de escenarios exagerados donde supuestamente reemplazarán personal
Da la impresión de que solo quien nunca ha resuelto procesamiento masivo de datos de forma confiable puede decir que los LLM no sirven. Incluso la traducción ahora puede manejarse con mucho más contexto
Personas confiables de la industria tech también dicen directamente que GenAI ayuda mucho a la productividad del desarrollo. El significado va desde 5% hasta 100%, así de amplio. Como mínimo creo que hay que aceptar que es una herramienta bastante útil. Para sostener esa afirmación no hacen falta números concretos como líneas de código, bytes o CPU
Seguramente la tecnología LLM sí terminará encontrando usos correctos, pero ya hay demasiada gente usándola mal y eso ya no se puede revertir. Muchísimos desarrolladores junior van a fracasar asumiendo riesgos, y se va a desperdiciar muchísimo capital. Las empresas tampoco pueden echarse para atrás y ya están todas all-in con esto