Hacia un arnés que pueda hacer cualquier cosa
Los desarrolladores debaten cuál es la mejor manera de “arnesar” los modelos de lenguaje grandes: ya sea mediante marcos genéricos, estilo Unix y centrados en archivos, como el propuesto sistema Ambiance, o mediante orquestadores específicos de dominio, de alcance estrecho, que envuelven herramientas y pruebas alrededor de un LLM. Un tema recurrente es trasladar tanto trabajo como sea posible a código y scripts deterministas —usando los LLM solo para decisiones y casos límite— mientras se lidia con problemas prácticos como los costes de tokens, la fiabilidad, la auditabilidad y las restricciones de plataforma. Muchos ven que los futuros flujos de trabajo de IA se parecerán a herramientas Unix componibles o a servicios a nivel de sistema operativo, con los LLM integrados de forma ligera en lugar de actuar como agentes autónomos y de libre recorrido.
Qué es un “arnés” y por qué le importa a la gente
- Se describe un arnés como el pegamento entre un LLM y las herramientas: analiza las llamadas a herramientas, ejecuta comandos (FS, red, etc.) y devuelve los resultados.
- Algunos lo ven como un “exoesqueleto agéntico” o un andamiaje determinista alrededor de un modelo por lo demás difuso.
- Otros se burlan de la terminología por parecer puro eslogan, pero aceptan la necesidad subyacente: limitar y estructurar el comportamiento de los LLM.
Flujos de trabajo deterministas frente a agentes “puros”
- Fuerte corriente a favor del determinismo: usar código y scripts reales para flujos repetibles; invocar LLM solo para juicios/casos límite.
- Patrones mencionados: árboles de decisión donde la mayoría de las hojas son “ejecutar script” y unas pocas son “preguntar al LLM”; código+tests como esqueleto, LLM como ayuda ocasional.
- La gente describe envolver herramientas como Claude Code/Codex en bucles deterministas externos (tests, git, comprobaciones de seguridad, hooks pre-commit).
- Algunos marcos (langgraph, ACP, etc.) se citan como buenos para orquestar estos bucles, aunque a unos pocos les desagradan los sistemas que hacen que “construir agentes” se sienta ritualizado.
Filosofía Unix, “todo es un archivo” y alternativas
- A muchos les gusta mapear conceptos de agentes a primitivas Unix: flujos de trabajo dirigidos por eventos, FS como estado compartido, FUSE, “agente como usuario de Linux” con permisos y correo.
- Otros rechazan “todo es un archivo” para los LLM, argumentando que para los modelos “todo son tokens/embeddings” y que las bases de datos vectoriales o el JSON tipado son más naturales.
- Algunos ven los archivos como un mínimo local pragmático: buenos tanto para humanos como para modelos; otros llaman anticuado al FHS y sugieren ideas tipo Nix/Plan 9.
Arneses genéricos frente a arneses específicos de dominio
- Varios sostienen que los arneses específicos de dominio (por ejemplo, para ingeniería de software) ya superan a los genéricos: ADR integradas, planificación, pruebas de comportamiento, gating estricto.
- Ejecutar LLM “en bruto” se compara con conducir sin frenos; otros informan haber abandonado arneses complejos y volver a CLIs más simples porque la complejidad extra no ayudaba.
Costes, tokens y practicidad
- Preocupación por los costes de tokens para vigilancia del FS o sondeos frecuentes; se sugiere disparar solo ante umbrales significativos de archivos en lugar de hacerlo continuamente.
- Algunos enfatizan pruebas, registro y scripts mínimos, no sobreingenierizados; la sobre-generalización se ve como una trampa de mantenimiento.
Recepción de Ambiance y la afirmación de “hacer cualquier cosa”
- Positivo: modelo mental nativo de Unix, enfoque ligero y auditable, un buen núcleo sobre el que construir variantes.
- Críticas: ideas “suaves”, poco claras sobre ganancias concretas frente a los sandboxes existentes; el soporte solo para macOS molesta a algunos; el branding de “puede hacer cualquier cosa” se ve como una exageración.