Category: AI

¿Quieres que la IA escriba código… o que lo arruine en silencio mientras nadie sabe por qué?

Tiempo estimado de lectura: 8 min

Introducción

Poca gente lo dice claro: no es que los LLMs sean malos. Es que los estamos soltando sin reglas. Y rápido.
Eso se nota cuando el triángulo Spec — Código — Tests se desincroniza a ritmo algorítmico. Y adivina qué aparece primero: deuda técnica.

Claire Le Goues en CMU lo adelantó hace años. No es novedad; es evolución. Reparación automática de programas y análisis de cobertura no son juguetes académicos. Son la columna vertebral de cualquier agente que quiera escribir código que aguante en producción.

Lo que estamos construyendo hoy se llama Compound AI. Y si lo manejas mal, es una mina.

Resumen rápido (lectores con prisa)

Compound AI: orquestación de múltiples modelos, validadores, bases de conocimiento (RAG) y un controlador.
Úsalo cuando necesites código reproducible, verificable y trazable en producción.
Importa porque reduce deuda técnica y fallos en producción al exigir specs operables, tests automatizados y decisiones registradas.
Funciona mediante pipelines: inputs tipados, transformaciones, validación automática y decision logging.

1) Por qué esto ya no es ML-only

Los investigadores pueden inventar algoritmos bonitos. Pero la ingeniería de verdad exige cosas aburridas: orquestación de estado, reintentos inteligentes, persistencia de memoria, latencias aceptables y observabilidad.
Necesitas backends robustos. PaaS. Infra que aguante agentes que lanzan 50 tareas concurrentes y esperan consistencia.

2) DSPy y la estructuración de llamadas

Frameworks como DSPy (o lo que quieras llamar ese nivel de orquestación) transforman llamadas LLM en flujos compilables.
Piensa en DSLs para IA: inputs tipados, outputs comprobables, rutas deterministas. Menos “ensayo y error” y más pipelines reproducibles.

3) Test-Time Inference y RLMs — lo que no es magia

En vez de quemar ciclos entrenando eternamente, gastas cómputo en inferencia inteligente.
Modelos de razonamiento (RLMs) exploran caminos, ejecutan validadores, comparan resultados y devuelven la versión que pasa las pruebas.
Sí: eso cuesta. Sí: merece la pena cuando lo que quieres no es una demo, sino software que no explote a las 2AM.

4) ¿Por qué necesitas ingenieros backend (con experiencia en PaaS)?

Porque la solución no es un notebook de investigación. Es operación:

• Orquestar estado entre modelos.
• Persistir trazas y decisiones.
• Manejar reintentos sin duplicar efectos.
• Escalar validadores y tests en paralelo.
• Aislar fallos y hacer rollback automáticos.

Si tu equipo no tiene esto, el agente será como un aprendiz con acceso root: peligroso.

5) El Triángulo que manda: Spec, Código, Tests

Si uno se desincroniza, todo se va a la mierda. Punto.

• La Spec debe ser operable. Markdown no basta. Necesitas specs con semántica, vinculadas a código y tests.
• El Código debe exponer por qué existe. No solo el “qué”.
• Los Tests no son opcionales. Deben ser ejecutados por el pipeline de agente antes de cualquier merge automático.

Implementación ≠ caja negra. Implementación comunica intención. Y esa intención debe quedar como dato.

6) Trazabilidad: la regla de oro

Cada decisión que toma un agente necesita un artefacto: quién, cuándo, por qué, y qué alternativas se descartaron.
Si el agente aplicó un “hack” para pasar un test, eso no puede quedar en un chat efímero. Tiene que vivir en tu repo, indexable. JSONL. PR metadata. Historia forense.

¿Por qué? Porque poder buscar “find all shortcuts” salva horas de debugging y evita que el mismo hack mute millón de veces.

7) Integración práctica: stack mínimo para empezar hoy

No necesitas toda una nave espacial. Esto es un MVP operativo:

• Orquestador: un servicio que planifica pasos y guarda estado (puede ser una pequeña cola + DB).
• Callers LLM: modelos rápidos (OSS) para edición y modelos potentes (RLM) para verificación.
• RAG vector DB para contexto y specs.
• Validadores: linters, pruebas unitarias, integración y un sandbox de ejecución.
• Decision store: archivo versionado (.decisions.jsonl) por PR.
• CI que no solo ejecuta tests, sino que verifica que la spec y los tests se actualizaron si el código cambió.

8) Un flujo mínimo (ejemplo)

1. Dev escribe o actualiza spec en formato operable.
2. El agente genera código y propone cambios en una rama.
3. Pipeline ejecuta tests + validadores.
4. Agente intenta optimizar. Si aplica un atajo, registra una decisión en .jsonl. Commit falla si no hay artefacto.
5. Reviewer aprueba la decisión o solicita cambio.
6. Merge + sync spec/tests/código.

Sí, agrega fricción. Es la fricción que salva producción.

9) Herramientas y patrones recomendados

• Esquemas validados: usa Zod o similar para validar outputs LLM cuando tocas boundaries.
• Captura de decisiones: .jsonl con campos: id, pregunta, decisión, autor (LLM/humano), timestamp, diff link.
• Umbrales configurables: “strict” para core, “lenient” para experiments.
• Rollbacks automáticos: si una decisión se revoca, tus pipelines deben poder revertir o marcar la rama como needing-fix.
• Observabilidad: traces de latencia, éxito de validadores, número de decisiones por PR.

10) Cultura, no solo stack

No automatices los valores. Automatiza la disciplina.
Si el equipo ve la herramienta como un juez en lugar de asistente, la odiarán. Hazla útil. Hazla pequeña. Hazla punitiva solo cuando tenga que serlo.

• Regla simple: cada cambio que no sea trivial necesita al menos una línea en la spec o una entrada en el decision log.
• No más “and let it run and we go answer some email and then we come back and now I get a decision and I’m like, that’s insane. Don’t do that.” Si vas a delegar, que quede registrado.

11) Riesgos reales y cómo mitigarlos

• Ruido: Demasiadas decisiones pequeñas saturan. Solución: umbrales y agrupación por categoría.
• Alucinaciones del LLM: Validadores estrictos y esquemas runtime.
• Duplicidad de specs: Fragmenta specs por dominio y mantén ownership.
• Ataques o leak de credenciales: todo secreto rotatable y accesible solo a procesos autorizados.

12) Qué cambiar en GitHub (si tuvieras la varita mágica)

• Markdown como entidad semántica. No solo texto.
• Linkar decisiones ↔ specs ↔ tests ↔ diffs en la UI.
• Búsqueda por “intención” (por ejemplo: “find decisions that relaxed auth checks”).
• Hooks nativos que prevengan merges sin decision artifacts.

13) Resultado: ¿qué ganas si lo haces bien?

• Menos deuda acumulada.
• Onboarding más rápido. Nuevos devs leen la historia de decisiones.
• Automatización sin descontrol.
• Auditoría real para compliance.
• Velocidad que no se convierte en caos.

14) No es sexy. Es efectivo.

Las grandes respuestas técnicas no son flashes de genialidad. Son procesos con disciplina.
Tenemos herramientas para bajar esa disciplina a la realidad operativa. Compound AI no es excusa para saltarse pasos. Es oportunidad para formalizarlos.

¿Quieres que lo vuelva práctico?
Puedo:
– Escribir el template de .jsonl para decisiones.
– Diseñar el flujo de CI (GitHub Actions) que bloquee merges sin sincronía spec↔tests↔code.
– Crear un checklist para ponerlo en marcha en 2 semanas.

Respóndeme “Dame el template” o “Quiero la CI” y te lo entrego listo para copiar.
Y recuerda: velocidad sin registro es solo una forma elegante de cavar tu propia trampa. Esto no acaba aquí.

Si quieres avanzar en pipelines, validación y decision logging con ejemplos prácticos y plantillas, revisa los recursos y experimentos de Dominicode Labs. Es una continuación lógica para equipos que quieren pasar de prototipos a procesos operables. Encontrarás ejemplos de decision logs y patrones de integración que encajan con lo expuesto arriba.

FAQ

• ¿Qué es Compound AI?
• ¿Cuándo debo usar validadores estrictos?
• ¿Qué debe contener un decision log (.jsonl)?
• ¿Cómo evito que el agente aplique hacks sin supervisión?
• ¿Qué cambios mínimos implemento en CI?
• ¿Cómo balancear fricción y velocidad?

¿Qué es Compound AI?

Compound AI es la orquestación de múltiples modelos, herramientas de validación, bases de conocimiento (RAG) y un controlador que decide qué modelo o herramienta usar, cuándo y cómo, para producir resultados reproducibles y verificables.

¿Cuándo debo usar validadores estrictos?

Usa validadores estrictos en componentes core que afectan seguridad, integridad de datos o disponibilidad. Para experimentos o prototipos puedes aplicar umbrales más lenient, pero documentándolo en el decision log.

¿Qué debe contener un decision log (.jsonl)?

Campos mínimos: id, pregunta, decisión, autor (LLM/humano), timestamp y diff link. Debe ser indexable y versionado por PR.

¿Cómo evito que el agente aplique hacks sin supervisión?

Bloquea commits sin artefacto de decisión; ejecuta validadores en CI; exige que cualquier atajo quede registrado en .jsonl y sea revisado por un humano antes del merge.

¿Qué cambios mínimos implemento en CI?

1) Ejecutar tests y validadores automáticamente. 2) Comprobar que specs y tests cambien si el código cambia. 3) Fallar merges que no incluyan decision artifacts.

¿Cómo balancear fricción y velocidad?

Define umbrales configurables: “strict” para core y “lenient” para experiments. Agrupa decisiones pequeñas y aplica políticas de batching para reducir ruido sin sacrificar trazabilidad.

¿Quieres que un modelo de IA deje de ser un loro elegante y empiece a hacer cosas reales por ti? Bienvenido a las Function calling.

Tiempo estimado de lectura: 5 min

Ideas clave

• Las Function calling permiten a un LLM devolver una estructura (normalmente JSON) indicando intención y parámetros para que el backend ejecute acciones reales.
• Existen dos estilos principales: JSON Schema (estricto) y formato libre (flexible), cada uno con trade-offs de seguridad y predictibilidad.
• Diseño seguro requiere validaciones, registros, sandboxes, rollback y, para operaciones críticas, un human-in-the-loop.
• Arquitectura práctica mínima: catálogo de herramientas, orquestador, executor aislado, auditoría y mecanismos de reversión.

Tabla de contenidos

• Título
• Ideas clave
• Introducción
• Resumen rápido (lectores con prisa)
• ¿Qué son, en una frase?
• ¿Por qué importa más que otra “nueva característica”?
• El ciclo real: cómo funciona sin volverte loco
• Dos estilos de herramientas
  • JSON Schema (estricto)
  • Formato libre (texto)
• ¿Cuándo usar cada una?
• Casos de uso que realmente importan
• Una advertencia sin eufemismos
• Regla de oro
• Human-in-the-loop
• Arquitectura práctica: qué componentes necesitas
• Un ejemplo mental (sin código complicado)
• Pistas y errores que nadie te dirá gratis
• Metáfora que pega y que funciona
• Urgencia realista
• ¿Quieres empezar ya?
• Dominicode Labs
• FAQ

Introducción

Poca gente habla claro sobre esto: las llamadas a funciones son la diferencia entre un chatbot inútil y un agente que mueve fichas en el mundo real. No es magia. Es arquitectura.

Resumen rápido (lectores con prisa)

Las Function calling permiten que un LLM deje de generar solo texto y devuelva una estructura (normalmente JSON) con intención y parámetros para que tu backend ejecute acciones reales. Usa JSON Schema para operaciones críticas y formato libre para prototipos; siempre valida y, para escrituras peligrosas, exige confirmación humana.

¿Qué son, en una frase?

Son el puente que permite a un LLM dejar de generar puro texto y pedirle a tu sistema: “oye, ejecuta esto”. El modelo no ejecuta nada por sí solo. Lo que hace es devolver una estructura (normalmente JSON) con la intención y los parámetros. Tu backend toma ese JSON, ejecuta la función y devuelve el resultado al modelo. Fin.

¿Por qué importa más que otra “nueva característica”?

Porque hasta ayer los LLMs eran como una enciclopedia parlante: óptimos para explicar, pésimos para actuar. Las Function calling rompen ese techo. Ahora el modelo puede:

• Consultar una base de datos en tiempo real.
• Lanzar un reembolso en Stripe.
• Generar y ejecutar una consulta SQL.
• Enviar un mensaje a Slack o disparar un workflow en n8n.

Es como si le dieras manos al loro: sigue hablando, pero ahora también abre puertas.

El ciclo real: cómo funciona sin volverte loco

No inventes un diagrama mental complejo. Hay cinco pasos claros y repetibles:

1. Tu app manda el prompt + la descripción de las herramientas disponibles.
2. El modelo decide: ¿lo puedo responder solo o necesito una herramienta?
3. Si necesita, devuelve un JSON con el nombre de la función y parámetros.
4. Tu backend valida y ejecuta la función real (API, DB, script).
5. Devuelves el resultado al modelo. Él sintetiza y responde al usuario.

Siempre hay una mano humana posible en el medio, sobre todo en operaciones peligrosas. Más abajo te explico por qué.

Dos estilos de herramientas: JSON Schema o texto libre

No todas las herramientas son iguales. Hay dos escuelas y cada una tiene su lugar.

JSON Schema (estricto)

Defines la función, tipos, campos obligatorios y enums. El modelo devuelve exactamente lo que espera tu backend. Es predecible, seguro y perfecto para integraciones REST y sistemas críticos. Ejemplo mental: la función crear_ticket exige titulo:string y prioridad:("alta"|"media"|"baja"). Punto y final.

Formato libre (texto)

El modelo genera un bloque de texto, código o comando. Ideal para análisis ad-hoc, scripts complejos o cuando necesitas flexibilidad absoluta. Requiere parsing robusto y sandboxes. Es más potente, pero también más peligroso si no controlas la entrada y la ejecución.

¿Cuándo usar cada una?

• Si tu operación cambia estados críticos (pagos, borrados, cambios de permisos): usa JSON Schema y validaciones humanas.
• Si estás haciendo análisis, prototipos o generación de consultas SQL que luego validarás: el modo libre puede acelerar prototipos, pero añade riesgo.

Casos de uso que realmente importan (no los anuncios)

• Customer Success: un agente recibe una queja, consulta el pedido en Shopify y, si procede, crea el reembolso en Stripe. Si la operación implica dinero, envía un checkpoint a un humano antes de ejecutar.
• DataOps: un usuario pide “ventas por región ayer”. El LLM traduce a SQL, ejecutas, devuelves los resultados y el modelo te da el resumen en lenguaje natural.
• Automatizaciones internas (n8n): en vez de tener flujos rígidos, el modelo decide qué nodos disparar, en qué orden y con qué parámetros, según la intención del usuario. Eso convierte tu automatización en dinámica, no en una secuencia predefinida.

Una advertencia sin eufemismos: los modelos mienten (a veces)

Alucinación de parámetros. Prompt injection. Errores sutiles. No es paranoia, es experiencia. Los LLMs pueden inventarse campos, malinterpretar enums o seguir instrucciones maliciosas ocultas en el prompt.

Regla de oro

• Automáticamente ejecuta lecturas (GET) si la operación es inofensiva.
• Para escrituras (POST/DELETE/PUT) exige validación adicional: reglas en el backend o confirmación humana. Siempre. No, no es opcional.

Human-in-the-loop: no es una filosofía, es ingeniería

La idea es simple: deja que el LLM proponga, pero que un humano o una lógica de negocio firme el cheque para operaciones críticas. Dos patrones útiles:

• Confirmación explícita: el LLM genera el payload, lo guardas y muestras a un humano para aprobar.
• Validación automática: reglas en el backend que verifican coherencia, límites y permisos antes de ejecutar.

Si haces esto bien, reduces riesgos drásticamente sin perder automatización.

Arquitectura práctica: qué componentes necesitas

No necesitas un stack del otro mundo. Necesitas disciplina.

1. Registro de herramientas: catálogo con descripciones y esquemas JSON.
2. Orquestador: recibe el JSON del LLM, valida y ejecuta. Aquí entra n8n, un backend propio o un servidorless.
3. Sandbox/Executor: si vas a ejecutar scripts generados por el modelo, hazlo en un entorno aislado.
4. Auditoría: logs de cada llamada, inputs y outputs. Esto no es solo para depurar; es para seguridad y cumplimiento.
5. Rollback y revocación: especialmente si permites crear o borrar recursos.

Un ejemplo mental (sin código complicado)

Usuario: “Reembolsa el pedido 123 si no se ha enviado.”

El LLM: decide que necesita verificar el estado del pedido → devuelve { action: "checkOrder", orderId: "123" }.

Tu backend: consulta y devuelve { status: "pending", paid: true }.

El LLM: con ese dato propone { action: "refund", orderId: "123", reason: "producto no enviado" }.

Tu backend: valida política de reembolsos y, si todo ok, lo ejecuta o pide OK humano.

Pistas y errores que nadie te dirá gratis

• Nunca confíes en que la respuesta del LLM está “bien formateada”. Valida siempre.
• Evita exponer funciones peligrosas sin restricciones de permiso.
• Ten límites de tasa para evitar loops: un LLM llamando a una función que regenere prompts puede convertirse en un bucle infinito.
• Si permites código, ejecútalo en containers efímeros con timeouts rígidos.

Metáfora que pega y que funciona

Las Function calling son como darle una tarjeta de crédito a un asistente. Con ella puede comprar lo que necesita, pero tú decides los límites, si necesita aprobación para ciertos tickets y a qué tiendas no puede entrar. Sin límites, te quedas sin dinero. Con límites y reglas, ganas productividad.

Urgencia realista

Si estás empezando a usar LLMs para interacción con sistemas reales y no diseñaste estas capas, estás pidiendo problemas. Empezar ahora con patrones sólidos (schemas, validaciones, humanos en la cadena) te ahorra migraciones dolorosas.

¿Quieres empezar ya?

Haz esto en 3 pasos prácticos:

1. Define las 3 funciones más críticas que quieres exponer (consulta de pedidos, emitir reembolso, crear ticket).
2. Escribe schemas JSON mínimos para cada una y prueba el loop: prompt → LLM → JSON → backend → resultado.
3. Añade validación humana para la más peligrosa y logs para todo.

No te dejo solo: ¿seguimos con la parte técnica?

Puedo enviarte:

• Un checklist para diseñar tus schemas JSON.
• Plantillas de orquestador para n8n con ejemplos de validación humana.
• Estrategias para sandboxing y rollback.

Respóndeme este mensaje y te doy la checklist completa y un ejemplo listo para copiar y pegar. Esto no acaba aquí: en la próxima entrega te muestro cómo migrar un flujo rígido de n8n a un agente LLM dinámico sin incendiar producción. ¿Te interesa?

Dominicode Labs

Si quieres ejemplos prácticos, plantillas y artículos relacionados con automatización, agentes y workflows, revisa Dominicode Labs. Es una continuación lógica para implementar patrones de Function calling en entornos productivos.

FAQ

• ¿Qué diferencia hay entre JSON Schema y formato libre?
• ¿Debo permitir que el modelo ejecute escrituras automáticamente?
• ¿Cómo prevengo loops entre el LLM y mis funciones?
• ¿Qué registros debo guardar?
• ¿Cuándo usar validación humana?
• ¿Es seguro ejecutar código generado por el modelo?