Filosofía UNIX y Scaffolding: Cómo Construir Sistemas de IA que Escalan
La mayoría de sistemas de IA fallan no porque la tecnología sea mala, sino porque intentan hacer demasiado a la vez. La Filosofía UNIX y el concepto de Scaffolding nos enseñan cómo construir sistemas que realmente funcionan y escalan.
Arriba: un agente todoterreno que falla vs agentes especializados que funcionan. Abajo: construye rápido con andamiaje, mejora después.
La Falacia del "Agente Todoterreno"
Cuando las empresas empiezan con IA, el error más común es intentar construir "un agente que haga todo". Un sistema que procese documentos, responda emails, gestione clientes, cotice servicios, y además haga café.
Esto nunca funciona. La complejidad crece exponencialmente. Los errores se multiplican. El mantenimiento se vuelve imposible. Y al final, terminas con un sistema que hace muchas cosas mal en lugar de pocas cosas bien.
Filosofía UNIX: "Haz Una Cosa y Hazla Bien"
En los años 70, los creadores de UNIX establecieron principios que siguen siendo válidos 50 años después:
Los Principios UNIX:
- •Haz una cosa y hazla bien: Cada programa debe hacer una tarea específica. Hacerla correctamente. No intentar ser todo para todos.
- •Construye para ser conectado: Diseña sistemas que puedan trabajar juntos. La salida de uno es la entrada de otro.
- •Simplicidad sobre complejidad: Elige la solución simple. Cuando tengas duda, elimina en lugar de añadir.
- •Texto plano como interfaz universal: Usa formatos estándar que cualquiera pueda leer y procesar.
Aplicado a Agentes de IA:
En lugar de "un agente que gestione toda la logística", construyes:
- • Mercury: Solo extrae datos de Bills of Lading. Nada más.
- • Venus: Solo cotiza rutas. Nada más.
- • Neptune: Solo predice demanda. Nada más.
- • Jupiter: Solo sincroniza tracking con APIs. Nada más.
Cada uno hace una cosa perfectamente. Luego los conectas en workflows que procesan operaciones completas.
Caso Real: BKLOG y la Filosofía UNIX
Cuando Carlos empezó con BKLOG (broker logístico), la tentación era construir "un sistema que haga todo el trabajo del broker". Eso hubiera sido un desastre.
Enfoque Equivocado (Todoterreno):
Construir un mega-agente que procese BLs, cotice rutas, gestione clientes, genere facturas, y haga seguimiento. Resultado: 6 meses de desarrollo, sistema inmanejable, nadie lo usa.
Enfoque UNIX (Especializado):
Empezar con una tarea: extracción de BLs. Construir Mercury. Hacerlo perfecto. Resultado: 2 semanas de desarrollo, en producción, ahorrando 40h/mes.
Lección: Mercury no sabe cotizar rutas. No gestiona clientes. No genera facturas. Solo extrae datos de BLs. Y por eso funciona perfectamente.
Scaffolding: Construye Rápido, Mejora Después
Scaffolding (andamiaje en español) es el concepto de construir estructuras temporales que te permiten llegar a tu objetivo más rápido, sabiendo que después las reemplazarás.
El Proceso de Scaffolding:
- Construye lo mínimo que funcione - No la solución perfecta, sino la que resuelve el problema hoy
- Usa herramientas temporales - APIs de terceros, scripts manuales, procesos semi-automatizados
- Aprende de la realidad - Descubre qué partes realmente importan cuando el sistema está en uso
- Reemplaza incrementalmente - Cambia una pieza a la vez por soluciones permanentes
- Remueve el andamiaje - Elimina lo que ya no necesitas sin miedo
Analogía de construcción:
Cuando construyes un edificio, usas andamios para llegar a lugares altos. Los andamios NO son parte del edificio final. Una vez terminado, los quitas. Nadie construye el edificio perfecto desde el primer día. El andamiaje te permite progresar rápido sin comprometerte a decisiones permanentes.
Ejemplo Real: Mercury v1 vs Mercury v2
Mercury v1 (Scaffolding):
- • Subida manual de PDFs
- • Procesamiento con Claude API directamente
- • Exportación manual a Excel
- • Revisión humana de cada resultado
- • Tiempo: 2 semanas de desarrollo
Mercury v2 (Producción):
- • Integración con email (recibe BLs automáticamente)
- • Pipeline de procesamiento con validaciones
- • Auto-exportación a matriz de naviera correcta
- • Revisión solo de casos ambiguos
- • Tiempo: 3 semanas adicionales, basado en aprendizajes de v1
Sin el andamiaje de v1, no sabríamos qué construir en v2. El andamiaje nos enseñó qué realmente importaba.
Cómo Aplicar Esto a Tu Proyecto de IA
No necesitas empezar con la arquitectura perfecta. Necesitas empezar con una victoria rápida:
1. Identifica UNA tarea específica
No "automatizar ventas". Eso es demasiado amplio. Mejor:
- • "Extraer datos de facturas PDF a planilla Excel"
- • "Responder consultas frecuentes de clientes"
- • "Clasificar tickets de soporte por urgencia"
- • "Generar resúmenes de reuniones desde transcripciones"
Test de especificidad: Si no puedes explicar la tarea en una frase simple, está demasiado amplia.
2. Construye la versión andamiaje (2 semanas máximo)
No arquitectura escalable. No pipelines complejos. Solo lo mínimo:
- • Scripts simples, no sistemas completos
- • APIs de terceros (Claude, OpenAI), no modelos propios
- • Intervención manual donde sea necesario
- • Guardar datos en CSVs/JSON, no bases de datos complejas
El objetivo es probar que funciona, no que sea perfecto.
3. Usa en producción (aunque sea tosco)
No esperes a que esté "listo". Ponlo a trabajar. Aprenderás más en una semana de uso real que en un mes de planificación. Monitorea errores, recolecta feedback, identifica cuellos de botella.
4. Reemplaza incrementalmente
Ahora que sabes qué funciona, mejora las partes críticas:
- • ¿El procesamiento es lento? Optimiza solo esa parte
- • ¿Los errores son frecuentes? Añade validaciones específicas
- • ¿La intervención manual es repetitiva? Automatiza ese paso
Cambia una cosa a la vez. Mantén el resto funcionando.
5. Elimina el andamiaje sin miedo
Cuando tengas la versión mejorada, borra el código viejo. No lo comentes "por si acaso". No lo mantengas "como backup". Bórralo. El andamiaje cumplió su propósito. Ya no lo necesitas.
Errores Comunes que Debes Evitar
Síndrome del "Primero Perfecto"
Pasar meses diseñando la arquitectura ideal antes de escribir una línea de código. Resultado: Nunca llegar a producción porque siempre hay "una cosa más" que mejorar.
Enamorarse del Andamiaje
Mantener código temporal "porque funciona". El andamiaje se convierte en deuda técnica. Solución: Establece una fecha límite para reemplazar o eliminar cada pieza temporal.
Construir para Casos Hipotéticos
"¿Y si algún día necesitamos procesar 1M de documentos?" cuando hoy procesas 50 al mes. Regla: Solo resuelve problemas que existen hoy.
Ignorar la Modularidad UNIX
Construir un monolito que hace 15 cosas mediocre en lugar de 3 agentes especializados que hacen 3 cosas perfectamente. Recuerda: Un agente, una responsabilidad.
El Camino Real Hacia Sistemas de IA que Funcionan
La Filosofía UNIX y Scaffolding no son solo conceptos técnicos. Son mentalidades que determinan si tu proyecto de IA termina siendo:
- ✓Un conjunto de agentes especializados que trabajan 24/7 ahorrando horas reales
- ✗Un sistema complejo que nadie entiende y que termina abandonado
Los principios son simples:
- • Haz una cosa y hazla bien (UNIX)
- • Empieza con andamiaje, mejora después (Scaffolding)
- • Conecta piezas simples en workflows complejos (Composabilidad)
- • Elimina sin miedo lo que ya no necesitas (Simplicidad)
La próxima vez que quieras construir "un agente que haga todo", recuerda a Mercury: hace una cosa, la hace perfecta, y por eso funciona.