Hay un patrón que se repite en equipos que adoptan IA por primera vez: empiezan con escepticismo total (“no me fío de nada que genere una IA”) y con el tiempo van hacia el extremo opuesto (“si lo dice el modelo, debe ser correcto”). Los dos extremos son errores costosos.

Las formas concretas en que los LLMs fallan

Alucinaciones de hechos: Los modelos inventan datos con la misma confianza con la que reportan hechos reales. Fechas, nombres, versiones de librerías, URLs, estadísticas. Si un LLM te dice que cierta función existe en una librería, verifica en la documentación antes de usarla en producción.

Fecha de corte del conocimiento: El modelo fue entrenado hasta una fecha específica. Cualquier cosa que haya ocurrido después (versiones nuevas de librerías, cambios de API, nuevos modelos) no la sabe. Puede responder con información desactualizada con total seguridad.

Falta de contexto de tu sistema específico: El modelo no sabe de tu arquitectura, tus decisiones de diseño, tu deuda técnica, tus convenciones de equipo. Puede generar código que funciona en general pero es incorrecto para tu contexto.

Razonamiento post-hoc: Como vimos con Chain-of-Thought, los modelos a veces generan explicaciones que parecen coherentes pero llevan a conclusiones incorrectas. El razonamiento bien formado no garantiza la corrección.

Lo que los LLMs hacen bien y merece confianza

Esto no significa que los LLMs no sean útiles. Son genuinamente buenos en:

  • Explicar conceptos conocidos
  • Generar ejemplos y variaciones de patrones bien documentados
  • Encontrar bugs en código que ya funciona mayoritariamente bien
  • Transformar formatos (JSON a TypeScript, SQL a ORM)
  • Primer borrador de código boilerplate
  • Sugerir alternativas que no habías considerado

La clave: son buenos generando opciones y explicaciones. Son menos buenos garantizando que algo es correcto.

La regla práctica

Para código que va a producción: la IA genera, el desarrollador verifica. Siempre.

Para información factual que va a citarse: verifica la fuente primaria. Si el modelo cita un dato, busca el dato original.

Para decisiones de arquitectura: usa el LLM para explorar opciones, no para elegir. La decisión final requiere contexto que el modelo no tiene.

El balance correcto

El escepticismo productivo no es desconfiar de todo lo que genera la IA. Es saber qué tipos de outputs requieren verificación y cuáles son suficientemente de bajo riesgo para aceptar directamente.

Un LLM que te explica cómo funciona un algoritmo merece menos verificación que uno que te da un fragmento de código que maneja autenticación. Calibra el nivel de verificación al nivel de riesgo.

Opinión editorial. Las categorías de errores están documentadas en investigación sobre LLMs de Anthropic, DeepMind y grupos académicos.