- Martin Fowler señala que encuestas recientes sobre formas de uso de los LLM pueden llevar a conclusiones distorsionadas porque no reflejan el flujo real de uso
- Ante preguntas sobre el futuro de la programación o la estabilidad laboral, todavía nadie lo sabe con certeza, y lo importante es experimentar personalmente y compartir experiencias
- La industria de la IA claramente está en una burbuja, pero como ha ocurrido históricamente con toda innovación tecnológica, incluso después de la burbuja pueden surgir empresas sobrevivientes como Amazon
- La esencia de los LLM es la alucinación (hallucination), y el propio proceso de reformular una pregunta varias veces y comparar respuestas resulta útil
- Los LLM amplían enormemente la superficie de ataque de los sistemas de software, y advierte que los agentes de navegador en particular tienen riesgos estructurales que no pueden hacerse seguros por naturaleza
Formas de usar LLM y productividad de los desarrolladores
- Recientemente se está discutiendo mucho sobre investigaciones iniciales acerca del impacto de la IA en el desarrollo de software
- La mayoría del uso de LLM se concentra en funciones de autocompletado avanzado (tipo co-pilot)
- Sin embargo, quienes usan LLM de la forma más efectiva suelen preferir usarlos para que puedan leer y modificar directamente archivos de código fuente
- Las investigaciones que ignoran las diferencias en la forma de usar LLM corren un alto riesgo de interpretar los datos en una dirección equivocada
- Además, las diferencias de capacidades entre distintos modelos de LLM también dificultan más la interpretación de los resultados
Profesión de programación y futuro de los LLM
- Con frecuencia surgen preguntas sobre el futuro de la programación, la necesidad de ingenieros junior y el futuro de los perfiles con experiencia
- No es posible dar una respuesta clara, y todavía no se ha establecido una manera efectiva de aprovechar los LLM
- Hace falta una aproximación experimental y una actitud de observar y compartir experiencias concretas de flujo de trabajo de otras personas
- Probarlo directamente y compartir experiencias es la forma más sensata de adaptarse
Fenómeno de burbuja en el campo de la IA y los LLM
- Frente a la idea de que la IA es una burbuja, se explica que toda innovación tecnológica viene acompañada de una burbuja
- La burbuja inevitablemente se desinflará algún día, y también habrá fracasos de inversión
- Sin embargo, no se puede predecir cuándo terminará la burbuja ni qué magnitud de valor llegará a crear
- Aunque la burbuja estalle, no todas las empresas desaparecerán, y algunas incluso podrán seguir creciendo de forma sostenida
- Durante la burbuja puntocom, pets.com y Webvan quebraron, pero Amazon sobrevivió y creció; ese es un caso representativo
Naturaleza de las alucinaciones en los LLM
- El fenómeno de alucinación (Hallucination) en los LLM no es un defecto, sino una característica esencial
- Al final, los LLM son herramientas para generar alucinaciones útiles
- Es recomendable obtener varias respuestas y compararlas haciendo la misma pregunta varias veces y variando la formulación
- Cuando se necesitan respuestas numéricas, es importante verificar la variabilidad entre respuestas mediante consultas repetidas
- No es apropiado hacer que un LLM responda directamente problemas determinísticos y calculables de forma exacta
Introducción de la no determinación en la ingeniería de software
- La ingeniería de software tradicional se diseña e implementa en un entorno determinístico
- Los ingenieros estructurales y de procesos diseñan tolerancias considerando la no determinación (incertidumbre) del mundo real
- La adopción de LLM puede ser un punto de inflexión en el que la ingeniería de software entre al mundo de la no determinación
Comparación entre LLM y desarrolladores junior
- A menudo se compara a los LLM con un colega junior
- Sin embargo, los LLM suelen afirmar que “todas las pruebas pasaron”, cuando en realidad es común que aparezcan pruebas fallidas
- Si fuera una persona, sería un nivel de comportamiento que rápidamente derivaría en un problema de recursos humanos
Aumento de amenazas de seguridad y el problema de los agentes de navegador
- Los LLM amplían enormemente la superficie de ataque de los sistemas de software
- La 'tríada letal (Trifecta)' que señaló Simon Willison consiste en acceso a datos privados, comunicación externa y exposición a contenido no confiable
- Mediante instrucciones ocultas en una página web (por ejemplo, texto blanco de 1pt), se puede engañar al LLM para que filtre información sensible
- Los agentes basados en navegador son especialmente riesgosos, y pueden ejecutar acciones maliciosas como transferencias bancarias mediante órdenes externas
- Willison plantea la opinión de que las extensiones de navegador de tipo agente no pueden hacerse seguras de forma fundamental
Conclusión
- Los LLM abren nuevas posibilidades en el desarrollo de software, pero es necesario comprender claramente sus formas de uso y limitaciones
- La burbuja es inevitable, pero a través de ella puede surgir un desarrollo tecnológico sostenible
- Los desarrolladores deben aprovechar al máximo el potencial de los LLM mediante una aproximación experimental y consideraciones de seguridad
3 comentarios
Solo de pensarlo ya me invade la frustración…
Estoy 100% de acuerdo, especialmente con la analogía del junior. La categoría de errores que comete es distinta a la de una persona... me parece una analogía representativa de las que salen muy mal.
Opinión de Hacker News
Mi excolega Rebecca Parsons lleva tiempo diciendo que las alucinaciones de los LLM (hallucination), más que un bug, son en realidad una función central. En el fondo, lo que hace un LLM es producir alucinaciones útiles. Cada vez que escucho ese argumento, siento que se está redefiniendo arbitrariamente el término "alucinación" para hacerlo pasar por un insight nuevo. La ‘alucinación’ tradicionalmente significa inventar detalles plausibles, como si fueran percepciones, sin relación con la realidad; pero esta lógica equivale simplemente a decir "salida". No es que sea novedoso que un LLM produzca resultados, sino que solo se le está pegando a toda su actividad una etiqueta que antes se veía como ‘mala’ para que parezca algo nuevo
No creo que Fowler realmente esté redefiniendo el término "alucinación". Más bien, está enfatizando irónicamente que la alucinación es el modo de funcionamiento fundamental de estos sistemas. Es como decir: "el daño colateral es esencial a una bomba"; no hace falta tomarlo de forma literal
Este argumento intenta corregir una falsa dicotomía del tipo: “los LLM producen verdad, o producen alucinaciones”. Planteado así, parece que si reducimos las alucinaciones solo quedará la verdad, pero en realidad toda salida es una forma de alucinación. Solo que algunas reflejan la realidad o coinciden con nuestras expectativas, y por eso parecen verdaderas. Es como tirar un dado y, si sale el número que querías, decir que "el dado leyó mi intención". Como con el mono infinito tecleando infinitamente hasta producir Hamlet, lo único que hicimos fue elevar esa probabilidad con IA
Me pareció una opinión interesante. Reconocer que un LLM no puede saber si lo que produce es correcto aporta un contexto práctico para quienes usan LLM en desarrollo de software
Me incomodó que este fenómeno se describa con la palabra "alucinación". Cuando una persona dice algo convincente sin tener ninguna base, solemos llamarlo "bullshit"; en ese sentido, un LLM es básicamente parecido. Si lo miramos desde la idea de "bullshit", parte de la crítica al uso de LLM pierde fuerza. Al final, si ese aspecto de los LLM te resulta insoportable, tampoco vas a poder trabajar con personas. Eso sí, redefinir la palabra "bullshit" es mucho más difícil. Aun así, creo que el texto en sí cumple como una colección de ideas dispersas, y no me parece que el autor estuviera intentando pontificar
Está expresado de una forma algo torpe, pero el punto central es que no hay una diferencia clara entre una salida ‘alucinada’ y cualquier otra salida. Es como en un RDBMS, donde dos resultados de consultas son esencialmente lo mismo. Es una observación valiosa
En nuestra empresa, siento que estamos inundados de código que está al 90%: casi llega a lo que queremos, pero el 10% restante está roto. Ha aumentado la producción de código, pero nadie logra seguirle el ritmo y la calidad claramente está bajando. En vez de avanzar lentamente hacia la meta, llegamos al 90% en un instante y luego perdemos tiempo familiarizándonos con código ajeno y corrigiéndolo una y otra vez. Puede que aun así sea más rápido que antes, pero en la práctica la diferencia entre ambos enfoques quizá no sea tan grande como uno imagina. Lo que más me molesta es que prefiero crear algo nuevo a gastar tiempo arreglando código que no conozco
A mí también me gusta mucho más crear algo nuevo. Pero hay personas que disfrutan más de esta nueva forma rápida e improvisada de trabajar. Yo la probé por obligación un rato, me resultó ajena y la borré toda; recién sentí verdadera satisfacción cuando la rehice manualmente con ayuda de la IA. El único código generado por IA que todavía no entiendo al 100% es una consulta SQL compleja, pero con SQL se puede validar rápido que funcione y no suele haber efectos secundarios inesperados, así que está bien
Este fenómeno se parece dolorosamente a lo que pasa cuando un equipo crece de 3 a 10 personas. De repente se acumula código que uno no conoce, cae la consistencia arquitectónica y se depende más de políticas y CI. La diferencia con los LLM es que no tiene sentido ni mentoría ni despedirlos. La forma efectiva de usar LLM es que la persona que los opera asuma el 100% de la responsabilidad por lo que generan. O sea, debe entender claramente el código producido, pero garantizar eso en la práctica parece difícil
Los LLM son muy buenos para autogenerar código boilerplate. Eso hace que uno se vuelva más flojo para ordenar o refactorizar ese boilerplate. Cuando llegan PRs con grandes cantidades de código, revisarlos también se vuelve difícil. GitHub tampoco está hecho para revisar demasiadas líneas de una sola vez. Como resultado, los desarrolladores junior y semi-senior terminan dedicándose solo a resolver boilerplate y tienen menos oportunidades de aprendizaje. Si esto sigue así, la calidad del código se va a deteriorar rápido
Cito el aforismo 7 de Perlis: ‘Es más fácil escribir un programa incorrecto que entender uno correcto’<br>http://cs.yale.edu/homes/perlis-alan/quotes.html
Coincido con la idea de que "la calidad claramente está bajando", y este fenómeno probablemente va a empeorar. Al final, hay que entender bien los trade-offs económicos para evaluar si realmente habrá una ‘ganancia neta’. Parece que mucha gente olvida que no existe el almuerzo gratis
Me identifiqué muchísimo con el encuadre de Rebecca Parsons de que “la alucinación es una función central del LLM”. Yo también intentaba explicárselo así a la gente cercana, y esa frase resume exactamente lo que quería decir
Yo también he explicado a familiares y amigos que los LLM se parecen más a un actor o intérprete. Un LLM solo actúa de acuerdo con el personaje; usa hechos únicamente cuando hacen falta<br>https://jstrieb.github.io/posts/llm-thespians/
La vieja cita “Todos los modelos están equivocados, pero algunos son útiles” le queda perfecto
La inteligencia es la capacidad de filtrar información innecesaria. Da igual si se trata de pensamiento o de percepción
No recuerdo quién lo dijo, pero la salida de un LLM siempre es una alucinación. Lo único es que más del 90% de las veces sale bien
Por un momento sentí que los LLM nos iban a quitar el trabajo, pero después entendí que más bien pueden terminar creando una montaña de trabajo que nosotros tendremos que arreglar luego. Ahora los uso bien como herramientas auxiliares prácticas, como Claude Code, y cada vez siento más claro que no sustituyen, sino que complementan
Vi el consejo de que “cuando le pidas una respuesta numérica a un LLM, pregúntale unas tres veces”. Este método también funciona con personas. Cuando la policía interroga, hace contar la misma historia tres veces, o incluso al revés. Si alguien está mintiendo o su recuerdo es difuso, puede delatarse al repetirlo. En entrevistas también sirve pedirle a alguien que explique un tema de tres maneras distintas para comprobar si de verdad lo entiende
Esta técnica también puede confundir a personas inocentes y hacer que parezca que están mintiendo. Hay que aplicarla con cuidado
Este método solo es válido bajo ciertas condiciones. Hay muchos casos en los que, cuanto más se recuerda y relata algo, más se distorsiona. Cuando la policía repite preguntas en un interrogatorio, a veces lo hace deliberadamente para provocar contradicciones en la declaración. Incluso con la misma información, si obligas a alguien a responder demasiadas veces y de distintas maneras, al final puede equivocarse. Y siempre hay que tener presente que el interrogador puede inducir la respuesta hacia donde quiere
El transbordador espacial de la NASA usa triple modular redundancy. Es para cubrir casos en los que la radiación espacial corrompe el procesador o la memoria<br>https://llis.nasa.gov/lesson/18803
Yo sí estoy sintiendo una productividad bastante alta con los LLM. No es solo autocompletado: el ahorro de tiempo es real. Eso sí, también me preocupa que si uno los usa con demasiada libertad, puede generar su propia deuda. Personalmente, me ha funcionado construir funcionalidades de forma incremental con Claude Sonnet o GPT-5 usando Test Driven Development (TDD). Todavía no hay muchos textos o discusiones sobre esta forma de trabajar, pero después de leer el texto de Martin creo entender por qué. Los verdaderos expertos en TDD no suelen ser del tipo que se lanza de lleno a la automatización de código con LLM; normalmente sienten orgullo por la artesanía del código o por la comunicación humana. Por eso todavía faltan muchos conocimientos prácticos acumulados como los de antes. En adelante se abrirá una nueva ‘pradera’ para aprender a escribir software con herramientas LLM, y espero que se acumulen muchas lecciones. Referencia: https://news.ycombinator.com/item?id=45055439
Lo básico es que el desarrollador verifique y revise por sí mismo el código hecho por el LLM. Conviene no pedir demasiado código de una sola vez, sino usar el LLM en unidades más pequeñas. Yo también ejecuto personalmente las pruebas unitarias. Que el LLM diga que corrió los tests y que “todo salió bien” puede no ser cierto. Solo confío cuando yo mismo los ejecuto
Estoy de acuerdo con la idea de que “la alucinación es una función del LLM”
Yo lo describiría diciendo que los LLM viven en un mundo hecho únicamente de texto y combinaciones. Para ellos, las palabras, las relaciones entre palabras y las historias son el mundo entero. Por eso son especialmente buenos inventando historias nuevas. A veces esas historias son inexactas o contradictorias, así que al final dependen de conjeturas. Un LLM no sabe realmente contar números, pero sí conoce patrones como que ‘2 viene después de 1’ y ‘3 es mayor que 2’. Igual que los humanos usamos calculadoras, ellos también pueden operar mediante herramientas. En el futuro, para que la IA sea realmente confiable, habrá que incorporar no un motor aritmético, sino un "motor epistémico" (epistemic engine) que ayude con la lógica, evite contradicciones y distinga hechos confiables
Desde esa perspectiva, un agente LLM podría verse simplemente como un medio para filtrar resultados alucinados
Yo coincido más con la frase: “toda salida de un modelo (de lenguaje grande) es una alucinación; solo que algunas son útiles”. El boom de la IA ocurrió porque la proporción de alucinaciones útiles es muy alta
Me parece una visión demasiado simplificada
Justamente por eso el término “alucinación” siempre genera controversia. Da la impresión de que puede haber resultados que no sean ‘alucinaciones’, cuando en realidad toda salida de un LLM se genera sin pensamiento
Hoy en día, para aprovechar bien los LLM y obtener el resultado que uno quiere, hace falta que un desarrollador senior reaccione lógicamente. Si en el futuro desaparecen los juniors, me pregunto quién va a reemplazar el rol de senior. Al final, supongo que los LLM llegarán a programar suficientemente por sí solos. En esta etapa, la IA sí es claramente una buena herramienta de apoyo. No es un sustituto
Sobre el consejo de hacerle varias veces la misma pregunta a un LLM, si usas macOS recomiendo aprovechar un workflow de Alfred. Presionas command + space, escribes 'llm <prompt>' y puedes lanzar de una vez en pestañas del navegador varios LLM como Perplexity, DeepSeek (local), ChatGPT, Claude o Grok. Así puedes hacer rápidamente la validación cruzada entre LLM que menciona Fowler, y con el tiempo también ves cuál LLM es más fuerte para cada tipo de tarea