La idea
Los equipos de operaciones pasan horas correlacionando incidentes manualmente: revisando logs, cruzando tickets, buscando patrones en hojas de cálculo. Es un proceso lento y propenso a errores, especialmente bajo presión.
Me interesaba ver si podía construir algo que tomara un CSV con incidentes y devolviera un diagnóstico estructurado — causa raíz, impacto, recomendaciones priorizadas — usando un LLM como motor de análisis pero con una arquitectura que no dependiera de un proveedor específico.
Cómo funciona
El flujo es deliberadamente simple. La complejidad está en lo que pasa por debajo.
Carga de datos
Se sube un CSV con incidentes. El parser acepta columnas en español e inglés, normaliza nombres, valida fechas y maneja campos vacíos. Máximo 500 filas.
Análisis con IA
Los datos se sanitizan y se envían con un prompt que solicita JSON estructurado en 6 secciones. La respuesta se valida con Zod antes de llegar al frontend.
Diagnóstico visual
Dashboard con tarjetas por sección: urgencia, resumen, problemas, causa raíz, impacto y recomendaciones.
Persistencia
Cada análisis se guarda en PostgreSQL vía Neon. Los últimos 50 quedan disponibles entre sesiones.
El diagnóstico
Cada análisis genera un reporte en 6 secciones. No es texto libre — es una estructura fija que el LLM llena con datos del CSV.
Nivel de urgencia
BAJO / MEDIO / ALTO con justificación basada en severidad y recurrencia.
Resumen general
Síntesis en máximo 150 palabras de lo esencial.
Problemas detectados
3 a 5 problemas con patrón, frecuencia e impacto estimado.
Causa probable
Hipótesis de causa raíz con correlación entre eventos.
Impacto en el negocio
Usuarios afectados, ingresos y operaciones.
Recomendaciones
3 a 5 acciones priorizadas con pasos concretos.
Lo que me interesaba resolver
Problemas de arquitectura relevantes cuando integras IA en una aplicación real.
Desacoplar la IA del negocio
Interfaz AIProvider con factory pattern. Cambiar de proveedor es crear un adaptador, no reescribir lógica.
Output predecible de un LLM
response_format: json_object + validación con Zod. Si el modelo se desvía del schema, el sistema lo detecta.
Mock que sirva de verdad
Analiza el CSV real y construye un diagnóstico coherente. Para demos, desarrollo y CI.
Resiliencia ante fallos
Retry con backoff exponencial en errores transitorios (429, 500, 502, 503).
Seguridad en el prompt
Datos truncados y sanitizados. Errores internos no expuestos. Prepared statements.
Testing con intención
179 tests en 20 archivos. Parser, prompts, retry, factory, API routes, DB y hooks.
Stack
Cada elección tiene un porqué.
Por qué lo construí
En mi trabajo diario tomo decisiones de arquitectura, defino patrones y reviso código de otros. Pero hay una diferencia entre opinar sobre cómo debería hacerse algo y construirlo desde cero con todas las restricciones reales: tiempo, scope, trade-offs.
Este proyecto fue eso. Un espacio para aplicar los mismos principios que uso profesionalmente — arquitectura desacoplada, patrones reales, testing con intención, manejo de errores robusto — pero con la libertad de tomar todas las decisiones yo mismo.
También quería explorar la integración con LLMs de forma seria. No como un wrapper de API con un textarea, sino como un componente más de la arquitectura: con contratos, validación, fallbacks y la posibilidad de cambiar de proveedor sin reescribir nada.
Si te interesa conversar sobre este proyecto o sobre arquitectura frontend en general, escríbeme.