Tag: AI

¿Te vas a mirar el correo mientras la IA reescribe tu código… y luego vuelves a casa de locos?

Tiempo estimado de lectura: 6 min

Resumen rápido (lectores con prisa)

Un agente que ejecuta cambios sin gobernanza introduce decisiones sin autoría en el repo. Necesitas un mecanismo externo que intercepte commits, extraiga decisiones y requiera aprobación, convirtiéndolas en artefactos versionables y auditable—eso reduce deuda técnica y mejora trazabilidad.

1) Lo que pasa cuando “lo dejamos correr”

Un agente se queda ejecutando tareas. Encuentra ambigüedades. Encuentra dependencias rotas. Para avanzar, toma atajos. Guarda esos atajos en su chat. Tú haces commit y pum: el código llega a la rama, los tests pasan y la intención se evapora.

Resultado: hacks documentados en conversaciones privadas, no en el repo. Atajos que nadie planeó. Deuda técnica que aparece al lado del despliegue.

2) Por qué esto es peor que un bug cualquiera

Un bug puedes rastrearlo. Una decisión sin autoría es un agujero negro. Nadie recuerda por qué cambó la fórmula de impuestos a las 3 AM. Nadie puede auditar la razón. Y cuando el problema explota en producción, el “blame” no sirve: no hay decisión firmada, solo un commit huérfano y un chat que nadie va a revisar.

3) La solución no es prohibir la IA. Es gobernarla.

No más fe ciega. No más prompts que funcionan en beta pero rompen en prod. Necesitamos que cada decisión que importe deje rastro formal. Que sea un artefacto. Que sea buscable. Que tenga autoría y timestamp. Que puedas preguntar: “¿por qué esto existe?” y obtener una respuesta concreta.

4) Plum: la plomada que obliga a decidir en serio

Imagina una herramienta que corre al lado de Git y te fuerza a responder. No genera código por ti. No es una skill adentro del LLM. Es un checkpoint.

Básicos del flujo

• plum init → crea .plum y .plumignore, añade hooks.
• Cambias código con un agente.
• Intentas git commit. Plum compara diffs y scans de traces.
• Si hay decisiones, el commit falla hasta que apruebes, edites o rechaces.
• Si apruebas, plum actualiza la spec (Markdown) y agrega una entrada .jsonl con: pregunta, decisión, autor, branch y timestamps.

¿La ventaja? Cuando vuelvas del mail, no te encuentras sorpresas sin contexto. Te encuentras una decisión con nombre y apellido.

5) No puede ser una “skill” del agente —y punto

Una skill dentro del LLM es una sugerencia. Las sugerencias se ignoran. La gobernanza debe estar fuera. Tiene que poder bloquear commits, integrarse en CI y ser determinista. Si es opcional, no sirve.

6) ¿Qué hay dentro del .jsonl y por qué importa?

Ese archivo no es solo logs. Es la historia de la intención del proyecto. Cada entrada contiene:

• El dilema técnico.
• La decisión tomada.
• Quién aprobó.
• Si fue propuesto por el LLM o por un humano.
• Vínculo a la diff/PR.
• Marcas de tiempo.

Eso convierte la intención en dato: indexable, auditable, útil para auditorías y forensics.

7) Problemas reales —sin romanticismos

• Deduping de decisiones es fuzzy. Detectar “la misma decisión” entre conversaciones distintas no es trivial. Requiere heurísticas y ajuste repo-específico.
• Rollbacks automáticos: si rechazas la decisión, idealmente el sistema revierte el cambio o pide al agente rehacerlo. Hoy eso es work-in-progress.
• Ruido: si cada hotfix dispara cinco decisiones, la herramienta es odiada. Necesitas umbrales configurables.
• Specs crecen como malas hierbas. Hay que shardearlas en requerimientos atómicos, y sí: un LLM puede ayudar a fragmentarlas, pero diseña el flujo.

8) Umbrales: sensibilidad y contexto

La clave práctica es permitir tolerancias dinámicas:

• Modo strict: todo pasa por aprobación (fintech, salud).
• Modo sane: decisiones no críticas se agrupan y se presentan en lote.
• Modo fast-lane: “dangerously approve all” para prototipos.
• Filtros por carpeta: core = strict; ui-experiments = lenient.

Hazlo configurable por módulo y por rama. No es capricho: es supervivencia.

9) Integración con DSPy y el determinismo

Cuando puedas validar con código, hazlo. Usa parsers, tests y reglas. Donde necesites LLMs (p.ej. parse semántico del spec), estructura las llamadas con DSPy: inputs y outputs tipados. Menos alucinaciones, más predictibilidad. Enrutamiento por velocidad: dedupe puede ir a modelos OSS rápidos; parsing pesado a modelos más potentes.

10) ¿Qué debería cambiar en GitHub?

Markdown no es solo texto. Debe ser ciudadano de primera clase. Tu spec tiene que ser operable, con vínculos directos a decisiones, código y tests. Visualizar esa malla en GitHub (decisiones ↔ requisitos ↔ tests ↔ diffs) debería ser trivial. Imagina abrir un diff de markdown y ver “este requisito cambia X líneas de código” con enlaces directos. Eso es la próxima generación de repositorios.

11) Cultura y proceso: lo que no puedes automatizar

No automatices la cultura. Exige que cada PR responda:

• ¿Qué decisión justificó este cambio?
• ¿Qué requirement se actualiza?
• ¿Qué test cubre el cambio?

Haz que la herramienta extraiga esos metadatos y los convierta en entradas .jsonl. Convierte la disciplina en hábito.

12) Checklist mínimo para empezar hoy (15–30 minutos)

1. Versiona tu spec en Markdown en la raíz del repo.
2. Asegura tests automatizados (si eres Python, Pytest; si no, prepara adapter).
3. pip install plum-dev
4. plum init → apunta specs.md y carpeta de tests.
5. Añade .plumignore (README, docs, assets).
6. Configura umbrales: prod = strict; feature branches = lenient.
7. Prueba: haz un cambio via agente, intenta commit, observa el fail y aprueba la decisión.
8. Ejecuta plum sync -> revisa gaps spec↔tests↔code.

13) Si no lo haces: la factura llegará

Velocidad hoy = caos mañana. Cuando explote algo crítico a las 2 AM, nadie sabrá por qué la regla cambió. El time-to-fix se multiplicará. La deuda técnica se vuelve refractorable, y cada refactor cuesta más que el ahorro inicial de haber delegado.

14) Beneficios reales (sí, más allá del miedo)

• Auditoría real para compliance.
• Onboarding más rápido: nuevos devs leen el árbol de decisiones.
• Menos debates eternos en PRs: la intención está documentada.
• Productividad con control: velocidad sin descontrol.

15) Cierre y acción concreta

No es sexy. Es necesario. Instala la plomada. Prueba en una rama. No por postureo: por supervivencia técnica.

Quiero ayudarte a empezar ya. ¿Quieres que te mande:

• el template de .jsonl listo para copiar,
• el flujo de PR + configuración de CI que bloquea merges hasta sync exitoso,
• y un checklist de integración de Plum en 15 minutos?

Respóndeme “Mándame el template” y te lo doy ahora mismo.
Y mientras lo instalas, recuerda esto: velocidad sin plomada es solo una forma elegante de cavar tu propia trampa.

Esto no acaba aquí.

Si quieres profundizar en prácticas de gobernanza y automatización que encajan con este enfoque, revisa Dominicode Labs para recursos y experimentos relacionados.

FAQ

• ¿Qué hace exactamente Plum cuando detecta una decisión?
• ¿Plum bloquea commits automáticamente?
• ¿Cómo se almacena la autoría y los timestamps?
• ¿Cómo evito que la herramienta genere ruido?
• ¿Se puede integrar Plum en CI/CD?
• ¿Qué contiene una entrada .jsonl?
• ¿Qué pasa si rechazo una decisión detectada?
• ¿Cómo empezar en 15 minutos?

¿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?

¿Quieres que tu proyecto salga de un prompt y se convierta en un producto real… o en otro experimento bonito que nadie mantiene?

Poca gente lo dice así: usar Lovable o Bolt.new no te salva de las malas decisiones. Te da velocidad y una sensación de omnipotencia. Eso es peligroso. Si no pones reglas, estándar y criterio técnico, la IA te entregará un prototipo brillante y un desastre a medio plazo.

Resumen rápido (lectores con prisa)

Qué es: Lista de buenas prácticas para usar IA en generación de código de producción.

Cuándo usarlo: Antes de delegar generación de pantallas, esquemas o integraciones críticas a un LLM.

Por qué importa: Evita deuda técnica, fugas de seguridad y vendor lock‑in.

Cómo funciona: Define contrato y plan primero; da contexto reducido al modelo y versiona prompts.

Tiempo estimado de lectura: 6 min

Ideas clave

• Ventana de contexto es tu presupuesto: modulariza y da snippets pequeños.
• Diseña tus tablas y ERD antes de pedir esquemas a la IA.
• Plan First: valida el plan antes de generar código.
• Evita vendor lock‑in y exige código estándar y control de versiones.
• Seguridad: nunca hardcodees keys en el cliente; usa BFF y Secret Manager.

1) El Context Window es tu presupuesto real

La IA no tiene memoria infinita. La ventana de contexto es el límite de atención del modelo. Si tu app es un mamotreto con 20 componentes, 10 rutas y 3 librerías por feature, la IA terminará olvidando piezas críticas.

Síntoma

Pides una nueva pantalla y la IA borra imports o rompe tests que estaban bien ayer.

Solución

• Modulariza. Divide en microcomponentes. Un componente = una responsabilidad.
• Un prompt = el componente y sus contratos (props, eventos, estado).
• Mantén snippets pequeños y referencias externas. No le metabolismes el repo entero en una sola petición.

Truco

La ventana de contexto es la mochila del modelo. Pocas cosas, y bien organizadas —no todo el campamento adentro.

2) Base de datos: tú diseñas las tablas, no la IA

Lovable y Bolt.new son rápidos para scaffolding. Pero pedirle a la IA que “genere el esquema” suele acabar en redundancias y campos con nombres raros tipo “user_name_2”.

• Regla dura: escribe el ERD primero. Define relaciones (1:N, N:M), claves foráneas, índices y tipos. Dale ese SQL o ese esquema inicial a la IA como contexto.
• Si usas Supabase, prepara las migrations y políticas RLS antes de que la IA genere las pantallas.
• Beneficio: menos prompts, menos correcciones, menos refactors dolorosos.

3) Plan First, Code Later — no es sugerencia, es mandamiento

Las herramientas muestran un plan. Léelo como si fuera el contrato que firmarás. Si el plan falla, el código será un remiendo.

Preguntas que debes hacer al plan

• ¿Entendió el flujo del usuario?
• ¿Qué librerías propone y por qué?
• ¿Qué estrategias de estado (local/global) va a usar?
• ¿Qué testing planea (unit, e2e)?

Si la IA propone algo raro, corrígelo en el plan. Luego ejecuta la generación.

Pro-tip: agrupa requerimientos complejos en un solo prompt largo (Lovable) o en un bloque bien definido con ejemplos (Bolt.new). Gasta menos mensajes y evitas contradicciones.

4) Vendor lock‑in y exportación: piensa en huir antes de casarte

¿Y si dentro de seis meses quieres migrar? ¿Qué pasa si Bolt.new cambia modelo de negocio? No te cases por default.

• Exige código estándar: React+Vite+Tailwind o lo que tu equipo soporte.
• Control de versiones: GitHub integrado y commits humanos. Que el repo sea clonable y arranque local.
• Evita dependencias propietarias: libs que solo funcionan dentro del editor de la plataforma son bombas de tiempo.

5) Manejo de diffs y errores cíclicos: corta el bucle

La IA puede entrar en bucles de “arreglar-esto-romper-aquello”. Si ves repetidos fallos en el mismo bloque, deja de pedirle que arregle. Entra y corrige manualmente.

• Técnica simple: si falla dos veces en el mismo lugar, resetea a un commit estable y arregla a mano. Luego vuelve a la IA.
• Por qué funciona: rompes el estado de error acumulado y le das a la IA un contexto limpio.

Tokens vs mensajes: cómo pagar menos sin perder eficacia

Bolt.new cobra por tokens. Lovable, por mensajes. Eso cambia la estrategia.

• Bolt.new (tokens): haz micro-prompts, optimiza longitud y reusa templates. Bueno para iteración rápida.
• Lovable (mensajes): agrupa instrucciones complejas en un solo prompt largo. Menos interacciones, más orden.

Stack “opinada”: si quieres otra cosa, pelea por ello

Estas herramientas aman React y Tailwind. Si tu stack es Angular, Laravel o un monolito legacy, prepárate para forzar mucho al modelo.

• Opción A: adapta tu stack al flujo (si puedes).
• Opción B: usa una herramienta más abierta (Cursor, Copilot, IDEs asistidos). Menor magia visual, pero mayor control técnico.

Seguridad: las API keys no son souvenirs

El error clásico: pedir a la IA que “integre Stripe” y conseguir un .env con la API key pegada en el frontend. Eso pasa. Mucho.

• Nunca pongas keys en el cliente.
• Siempre: BFF (Backend-for-Frontend) + Secret Manager (AWS Secrets Manager, Vault).
• Recomendación: short-lived tokens y rotación automatizada. Kill-switch para revocar keys si algo huele raro.

Prompt versioning: trata el prompt como código

Un cambio de prompt puede cambiar comportamiento entero. Versiona tus prompts como si fueran migrations.

• Estructura mínima: promptId, version, author, changelog, template.
• Guarda promptId y promptVersion en metadatos de cada request para reproducibilidad y auditoría.

Moderación y trust & safety: no lo ignores

Tus usuarios intentarán generar logos, contenido protegido o imágenes que no deberías producir.

• Filtra y modera en el BFF antes de llamar al modelo.
• Bloquea términos sensibles. Si hay duda, manda a revisión humana.
• Log: guarda hashes de prompts, no texto completo si hay PII.

Observability: métricas que realmente importan

No solo logs. Métricas que salven tu día.

• Latencia E2E por prompt.
• Cost per generation (USD).
• Cache hit ratio.
• Rate of regeneration per user.
• Incidencias de prompt-injection.

Cache: ahorra dinero y tiempo

Si dos usuarios piden “perro astronauta”, no generes dos imágenes nuevas.

• Hash(prompt + constraints) → Redis.
• TTL adaptativo: prompts comerciales frecuentes TTL largo; prompts únicos TTL corto.
• Cache hit = ahorro directo.

Testing y CI: no dejes que la IA improvise tu pipeline

• Mockea LLM en tests unitarios.
• Contract tests: respuesta del modelo debe cumplir schema JSON.
• Canary releases para nuevos prompts: 1% tráfico, luego escalas.

UX que no traicione la IA

• Siempre: transparencia. Indica cuando la respuesta es generativa.
• Si confidence < 0.6: pide confirmación humana antes de acciones sensibles.
• Muestra el prompt o la interpretación antes de ejecutar (editable).

Playbook anti-abuso (lo que debes tener listo)

• Rate limits y quotas por usuario.
• Circuit breaker y fallback a placeholder.
• Kill switch global para detener generación masiva.
• Alertas de gasto (thresholds diarios).

Plantilla rápida: prompt “Plan First”

Usa esta plantilla antes de generar código. Pégala como prompt inicial.

System: “Eres un generador de código que sigue estrictamente el plan. Responde con: 1) Plan de archivos; 2) Librerías y versiones; 3) Tests a crear; 4) Código. El prompt del usuario es: {{user_prompt}}. Las reglas de la marca: {{brand_rules}}. Stack: React 18, Vite, Tailwind 3.2. Output: JSON con campos plan, files[], tests[].”

Si la IA no responde en ese formato, rechaza y reprompt.

Checklist mínimo antes de pulsar “deploy”

• [ ] ERD definido y migrations escritas.
• [ ] Prompt versionado y almacenado en repo seguro.
• [ ] BFF implementado con secret manager y rate limiting.
• [ ] Moderación automática y paths de escalado humano.
• [ ] Tests con mocks LLM.
• [ ] Canary rollout para new prompts.
• [ ] Observability y alertas de coste.

Errores que acaban con productos bonitos

• Permitir que la IA toque el schema sin revisión.
• Dejar keys en el bundle para facilitar “hackeo” por bots.
• No versionar prompts: si algo falla, no puedes reproducir.
• Depender de wrappers no oficiales (Midjourney via Discord): buen gusto para hobbies, mal gusto para negocios.

Qué hacer ahora (acción inmediata)

1. Si estás probando: agrega promptVersion y un traceId a cada petición.
2. Si vas a producción: crea el BFF en la próxima semana. No hay atajos.
3. Si tienes equipo: asigna ownership de prompts a un rol (AI Owner) con procesos de CI.

Si quieres que te lo entregue listo

Responde “QUIERO EL KIT” y te doy:

• Esqueleto BFF Node/Nest con secret manager y rate limiting.
• Plantilla de prompt versionado y CI para canary prompts.
• Component React + Vite + Tailwind con patrón Plan First integrado.
• Tests e2e que simulan LLM.

Dominicode Labs

Si quieres explorar workflows y agentes aplicados a producto, puedes ver recursos y experimentos relacionados en Dominicode Labs. Es un complemento lógico si trabajas con automatización y agentes en entornos de producción.

FAQ