Cuándo NO usar IA: Identificando cuellos de botella donde el código puro aún vence
No todos los problemas técnicos deben resolverse con inteligencia artificial. Conoce dónde fallan las IA y por qué el código clásico sigue siendo insustituible.
La era de la inteligencia artificial generativa ha traído un entusiasmo comprensible. Los LLM (Large Language Models) pueden escribir código funcional, estructurar ideas para publicaciones de blog y traducir términos técnicos complejos manteniendo el tono de voz original del autor.
Sin embargo, este entusiasmo ha generado un efecto secundario común en la ingeniería: la tendencia a usar la herramienta más nueva para absolutamente cualquier problema. Si la única herramienta que tienes es un LLM, cada problema parece un prompt.
La fiebre de los LLM en todo
Actualmente, vemos soluciones de software complejas que utilizan llamadas a API de IA para tareas extremadamente simples, como extraer una fecha de una cadena de texto, validar el formato de un correo electrónico o clasificar un texto en tres categorías fijas.
Aunque un LLM puede hacer esto razonablemente bien, utilizar inteligencia artificial para tareas puramente lógicas o matemáticas es el equivalente a contratar a un consultor sénior solo para organizar tu carpeta de descargas.
Dónde falla la IA
Los modelos probabilísticos de lenguaje funcionan prediciendo la siguiente palabra más probable basándose en patrones estadísticos. No tienen un mecanismo de lógica computacional real ni conciencia de reglas matemáticas estrictas.
- Subjetividad frente a Rigor: La IA es excelente para tareas subjetivas (ej. “mejora el tono de este texto” o “traduce manteniendo la formalidad”). Falla cuando la respuesta debe ser binaria y exacta (ej. “calcula si esta transacción de trading infringe la gestión de riesgos del 2%”).
- Reproducibilidad: El mismo prompt ejecutado en momentos diferentes puede generar variaciones en la estructura de salida. En sistemas que dependen de contratos de datos rígidos (API, integraciones bancarias), esto es un desastre.
- Alucinaciones estructurales: Incluso al forzar la salida en formato JSON, hay momentos en los que la IA rompe la estructura sintáctica, invalida el JSON o inventa claves que no existían en el esquema solicitado.
Costes y latencia: La realidad olvidada
Hacer una llamada de API a OpenAI, Anthropic o ejecutar un modelo local (como Llama 3) requiere recursos computacionales inmensos. Esto se traduce en dos grandes enemigos de los sistemas eficientes:
- Latencia: Una llamada de red a un modelo de lenguaje rara vez tarda menos de unos pocos cientos de milisegundos, llegando fácilmente a segundos. Una regex en Python se ejecuta localmente en menos de 1 milisegundo.
- Coste financiero: Mientras que procesar 1 millón de cadenas con regex cuesta fracciones imperceptibles de centavos de energía en tu VPS, hacer lo mismo mediante llamadas de API de IA puede costar decenas de dólares mensuales de forma recurrente.
El poder de las soluciones deterministas
El verdadero “Systems Builder” entiende que la IA debe ser un complemento, no la base.
Si un problema se puede resolver con un algoritmo determinista tradicional (regex, estructuras de decisión, análisis estructurado de JSON, bases de datos relacionales), el código clásico siempre vencerá en rendimiento, previsibilidad y coste.
En nuestra cadena de contenido, por ejemplo, la IA se utiliza para generar la traducción técnica inicial y sugerir enlaces. Sin embargo, ensamblar el frontmatter de Markdown, validar las rutas de las imágenes, calcular el tiempo de lectura y publicar a través de la API de GitHub son controlados por flujos tradicionales en n8n y JavaScript.
No intentes adivinar probabilísticamente lo que se puede calcular deterministamente.