Las críticas a los LLMs son ciertas. Los usamos igual

En pocas palabras: Porque la utilidad supera al reproche. En la Local-First Conf de Berlín (2026), Armin Ronacher —creador de Flask— reconoció que usa LLMs a diario pese a sus fallas: alucinaciones, sesgos y costo energético son reales, pero la ganancia de productividad los vuelve, hoy, difíciles de resistir.

Las críticas a LLMs legítimas existen y siguen vigentes en 2026: los modelos alucinan, arrastran sesgos, consumen energía y se entrenan con datos de origen dudoso. Y aun así, mucha de la gente que las reconoce los sigue usando todos los días. Esa contradicción quedó al desnudo esta semana en la Local-First Conf de Berlín.

Un modelo de lenguaje grande (LLM) es un sistema de IA entrenado sobre enormes volúmenes de texto para predecir la siguiente palabra y generar respuestas en lenguaje natural, como Claude, GPT o Gemini. Las críticas a estos modelos apuntan a fallas concretas: inventan datos, reproducen prejuicios y tienen un costo ambiental real. El debate de 2026 no es si esas fallas son ciertas, sino por qué los seguimos usando igual.

¿Cuáles son las críticas más válidas a los LLMs?

Las críticas técnicas más sólidas a los LLMs son cinco: las alucinaciones, el sesgo algorítmico, el consumo energético, la privacidad de los datos de entrenamiento y la dependencia de fuentes de calidad desigual. No son quejas ideológicas ni nostalgia. Son limitaciones documentadas que siguen sin resolverse del todo, aunque los modelos de 2026 las mitiguen mejor que los de hace dos años.

Ponele que le pedís a Claude que te arme una query SQL y lo que te devuelve referencia una tabla que no existe en tu base. Eso es una alucinación: el modelo genera algo plausible pero falso, con total seguridad. No “miente” en el sentido humano. Predice tokens probables, y a veces lo probable no es lo cierto.

El sesgo es otro frente. Un modelo entrenado sobre internet reproduce lo que hay en internet, con sus prejuicios incluidos. Si los datos sobrerrepresentan una visión, el modelo la va a favorecer sin avisarte. Relacionado: cómo proteger tus datos en herramientas IA.

Después está lo ambiental. Entrenar y correr modelos grandes demanda cómputo, y el cómputo demanda energía y agua para refrigeración. Es una crítica válida, aunque el impacto exacto varía según el modelo y el datacenter, y muchos operadores no publican cifras auditables (tomá con pinzas cualquier número redondo que veas circular).

Crítica	Qué la causa	¿Se puede mitigar?
Alucinaciones	El modelo predice texto probable, no verifica hechos	Parcial: RAG, citar fuentes, revisión humana
Sesgo algorítmico	Reproduce prejuicios de los datos de entrenamiento	Parcial: filtrado, fine-tuning, evaluaciones
Consumo energético	Cómputo intensivo para entrenar e inferir	Difícil: hardware más eficiente, modelos chicos
Privacidad de datos	Entrenamiento sobre texto sin consentimiento claro	Difícil: es una decisión de diseño del proveedor
Fuentes cuestionables	No distingue calidad al aprender	Parcial: curaduría del corpus, atribución

¿Por qué seguimos usando LLMs si reconocemos estos problemas?

Los seguimos usando porque, en tareas concretas, funcionan bien y ahorran tiempo real. El propio Theocharis lo dice sin vueltas en su artículo: “casi coincido con todas las críticas a los LLMs, y aun así los uso mucho”. No es incoherencia. Es reconocer que una herramienta puede ser defectuosa y útil al mismo tiempo.

¿Dónde rinden de verdad? En asistencia para programar, en generar borradores que después editás, en explorar un tema desconocido, en prototipar rápido. En todos esos casos vos seguís siendo el que decide. El modelo propone, vos disponés.

El tema es que la utilidad no borra las fallas. Un LLM te acelera el primer borrador de una función, pero si lo mandás a producción sin leerlo, te comés el bug. La madurez está en usarlo sabiendo dónde te puede fallar, no en creerle todo ni en negarte a tocarlo por principio.

Lo interesante es que el escepticismo y el uso conviven en la misma persona. La disonancia (así la llama el autor) no es hipocresía: es lo que pasa cuando una tecnología imperfecta igual te resuelve problemas todos los días. Esto se conecta con lo que analizamos en las capacidades reales de ChatGPT.

¿Por qué Pi.dev auto-cierra casi todos los PRs generados por LLMs?

Pi.dev auto-cierra casi todos los PRs e issues porque su propio creador quedó sepultado bajo el flujo de contribuciones automáticas. Lo confirmó Armin Ronacher en vivo, en la Local-First Conf de Berlín, cuando le preguntaron cómo manejaba la avalancha de pull requests generados por IA. Su respuesta: los cierran casi todos.

El detalle que lo hace jugoso: Ronacher no es cualquiera. Creó Flask, fue de los primeros en el equipo de Sentry, y fundó Earendil, la empresa detrás de Pi.dev, que él mismo define como un “harness de agentes de código abierto”. O sea, construye una herramienta para trabajar con LLMs y su creación lo inunda con lo que produce.

Ronacher matizó que uno no debería sentirse desalentado de abrir un PR, “porque el humano siempre va a brillar”. Y en el sitio de Pi lo dejan escrito: “En un mundo que se precipita hacia la IA, creemos que los humanos son los mejores agentes”. Un fabricante de agentes de IA diciendo que el mejor agente es una persona. Ahí está toda la contradicción, condensada.

¿Qué tan común es esta contradicción en la industria tech?

Es sistémica, no un caso aislado. En la misma Local-First Conf, mientras varios oradores lanzaban críticas duras a la IA, el autor observaba desde la platea que buena parte del público tenía Claude Code abierto en la pantalla. Criticar y usar, al mismo tiempo, en la misma sala.

No es hipocresía individual. Es el estado real de la industria en 2026. El developer que reniega de Copilot y lo tiene activado. El que escribe hilos sobre los peligros de la IA desde un editor con autocompletado por LLM. La persona que arma la herramienta y la que la usa comparten la misma disonancia.

¿Y por qué pasa? Porque el costo de quedarse afuera es concreto y el costo de las fallas es difuso. Vos ves el tiempo que ahorrás hoy. El sesgo, la alucinación o el impacto ambiental los pagás más tarde, o los paga otro. Ese desbalance explica buena parte del comportamiento. Sobre eso hablamos en entender cómo funcionan internamente.

¿Existe una forma consciente de usar LLMs reconociendo sus límites?

Sí, y la diferencia no es “usar o no usar”, sino uso consciente contra uso ciego. El uso consciente parte de una idea simple: el modelo es un asistente falible, no un oráculo. Todo lo que produce pasa por tu criterio antes de convertirse en decisión.

Algunas prácticas concretas que separan un uso maduro de uno temerario:

• Auditá cada output que importe: si el resultado va a producción, a un cliente o a una decisión real, leelo y verificalo. El modelo suena seguro incluso cuando se equivoca.
• No automatices decisiones humanas críticas: contrataciones, diagnósticos, temas legales o financieros necesitan una persona responsable al final de la cadena.
• Cuidá qué datos le pegás: lo que ponés en un prompt puede salir del control de tu organización. Con información sensible, pensá dos veces.
• Pedí y validá fuentes: cuando el modelo afirma un dato, buscá la fuente original. Si no existe, probablemente lo inventó.

Usado así, el LLM se parece más a un colega junior brillante pero distraído que a un sistema en el que delegás a ciegas. Vos revisás, vos firmás.

¿Pueden los humanos mantener la agencia si las máquinas hacen cada vez más?

La pregunta de fondo es si conservamos criterio propio a medida que delegamos más tareas. La consigna de Pi.dev (“los humanos son los mejores agentes”) suena a marketing, pero apunta a algo verdadero: la agencia no se pierde por usar la herramienta, se pierde por dejar de revisar lo que produce.

El caso de Ronacher lo muestra bien. Él no abandonó los LLMs. Puso un filtro humano donde el volumen automático se volvía inmanejable. Auto-cerrar PRs es, en el fondo, una forma de reafirmar que la decisión final la toma una persona.

El dilema personal de usar un LLM sabiendo que falla es el mismo dilema, en chico, de toda la industria: cómo aprovechar la eficiencia de la máquina sin entregarle la soberanía sobre lo que importa. Subís el modelo, lo probás, te ahorra horas, lo integrás a tu flujo y de golpe te descubrís aceptando sugerencias sin leerlas, aprobando cambios sin entenderlos, delegando criterio que antes ejercías vos, y ahí es donde la comodidad se transforma en abdicación. El punto no es frenar la herramienta. Es no soltar el volante. Cubrimos ese tema en detalle en opciones de Google en inteligencia artificial.

Errores comunes al usar LLMs (y cómo corregirlos)

• Creer que si suena seguro, está bien: el modelo genera con el mismo tono confiado la verdad y la alucinación. Corrección: verificá los datos críticos contra una fuente real antes de usarlos.
• Automatizar decisiones sin revisión humana: conectar un LLM directo a una acción irreversible es pedir problemas. Corrección: dejá siempre un punto de aprobación humano en flujos sensibles.
• Pegar información confidencial en el prompt: datos de clientes, credenciales o código propietario pueden escapar de tu control. Corrección: anonimizá o usá modelos con garantías de privacidad para material sensible.
• Confundir escepticismo con abstención: criticar los LLMs no te obliga a no usarlos, ni usarlos te prohíbe criticarlos. Corrección: sostené las dos cosas, es la postura más honesta.

Preguntas Frecuentes

¿Qué es una alucinación en un LLM?

Una alucinación es cuando un modelo de lenguaje genera información falsa o inventada presentándola como cierta. Ocurre porque el LLM predice el texto más probable, no verifica hechos contra una base real. Por eso puede citar una función, una tabla o un estudio que no existe, con total seguridad.

¿Es una contradicción usar IA si conocés sus problemas?

No es una contradicción, es una postura pragmática. Reconocer que una herramienta falla y usarla igual para lo que sí hace bien es criterio, no incoherencia. El error sería usarla a ciegas o rechazarla por dogma; el punto medio es el uso consciente y revisado.

¿Qué es Pi.dev?

Pi.dev es un “harness de agentes de código abierto” desarrollado por Earendil, la empresa que fundó Armin Ronacher, creador de Flask y ex integrante temprano de Sentry. Es una herramienta para trabajar con agentes de IA en tareas de programación. Su lema oficial sostiene que “los humanos son los mejores agentes”.

¿Por qué Pi.dev cierra los PRs generados por IA?

Porque el volumen de pull requests automáticos se volvió inmanejable. Ronacher lo explicó en vivo en la Local-First Conf de Berlín: auto-cierran casi todos los PRs e issues para no quedar sepultados bajo contribuciones generadas por LLMs. Es un filtro humano frente a la producción masiva de la propia herramienta.

¿Cuáles son las críticas técnicas más válidas a los LLMs?

Las cinco más sólidas son las alucinaciones, el sesgo heredado de los datos, el consumo energético del cómputo, la privacidad del material de entrenamiento y la calidad desigual de las fuentes que absorben. Son limitaciones documentadas y vigentes en 2026, mitigables en parte pero no eliminadas.

Conclusión

Lo que cambió no es la tecnología, es la honestidad con que la industria empieza a hablar de ella. En 2026 ya casi nadie serio dice que los LLMs son perfectos, y casi nadie serio propone abandonarlos. La escena de Berlín (una sala llena de gente con Claude Code abierto escuchando críticas a la IA) es la foto exacta del momento.

Por qué importa: si vas a usar estas herramientas, hacelo como Ronacher maneja Pi.dev, con un filtro humano donde el volumen o el riesgo lo justifiquen. Auditá lo que produce, no le delegues decisiones críticas, cuidá tus datos. La disonancia entre criticar y usar no se resuelve eligiendo un bando. Se resuelve manteniendo el criterio propio mientras aprovechás lo que la máquina sí hace bien.

Fuentes

• The LLM Critics Are Right. I Use LLMs Anyway – artículo original de Manuel Theocharis
• Pi.dev – harness de agentes de código abierto de Earendil (Armin Ronacher)