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?

¿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

¿Quieres que tu e‑commerce deje de vender fotos y empiece a fabricar deseos en tiempo real?

Tiempo estimado de lectura: 4 min

Ideas clave

• Generación de imágenes en tiempo real: es una palanca de conversión que exige arquitectura, cache, moderación y observabilidad.
• BFF controlado: valida prompts, aplica reglas de marca y evita exponer la cuenta de la empresa al cliente.
• Cache y coste: hash de prompt → Redis + TTL inteligente y políticas de rate limiting para evitar facturas inesperadas.
• UX y mock‑ups: mostrar progreso, confirmar cuando la confianza es baja y combinar imágenes generadas con mock‑ups reales.
• Moderación y legal: bloquear logos/trademarks y guardar metadata (promptId, traceId) para reproducibilidad y cumplimiento.

Poca gente lo dice tan claro: la generación de imágenes al vuelo no es un capricho estético. Es una palanca de conversión. Si la ejecutas mal, quemas presupuesto y confianza. Si la ejecutas bien, vendes productos que no existían cinco minutos antes.

Te voy a dar el patrón que usan los equipos que ya están experimentando con esto en producción. Sin rodeos. Con lo técnico que importa. Y con las trampas que nadie te advierte hasta que te llega la factura.

Resumen rápido (lectores con prisa)

Qué es: Generación de imágenes en tiempo real integrada en el flujo de e‑commerce para producir mock‑ups o productos personalizados al momento.

Cuándo usarlo: Cuando el valor de conversión supera el coste por generación y puedes controlar cache, moderación y latencia.

Por qué importa: Aumenta la conversión y reduce fricción para productos personalizados; mal implementado genera coste y pérdida de confianza.

Cómo funciona (resumen): Cliente → BFF (validación, prompt‑engineering, moderación, cache) → Modelo generativo → Storage/CDN → cliente con URL y metadata (promptId, traceId).

1) Arquitectura mínima que funciona (y no te deja expuesto)

Cliente Angular

• captura prompt, muestra estado, aplica mock‑up en Canvas/Three.js.

BFF (Node/Nest)

• valida prompt, aplica prompt‑engineering de marca, moderación, cache, llama a la API generativa.

Storage CDN (S3 + Cloudfront)

• guarda imagen final, sirve al cliente por URL.

Redis

• cache de hash(prompt) → URL.

Observability

• traces (OpenTelemetry), métricas de latencia y coste.

Metáfora rápida: el BFF es el taller de estampación. El cliente es la tienda con el maniquí. No mandes clientes a la fábrica con la tarjeta de crédito de la empresa.

2) ¿DALL‑E 3 o Midjourney? La decisión que define tu stack

DALL‑E 3: integra, documentado, estable. Latencia predecible. Útil para flujos sin sorpresas.

Midjourney: estética potente, pero sin API oficial. Inestabilidad + riesgo legal. Úsalo solo para pruebas internas o moodboards.

Regla: si es negocio y producción, DALL‑E (o alternativa con SLA). Si es inspiración artística, Midjourney en sandbox.

3) UX que no te mata la tasa de conversión

• Primera regla: muestra progreso. El usuario debe saber que algo está sucediendo (ondas, barra y texto: “La IA está pintando tu idea”).
• Segunda regla: siempre confirmación si confidence < 0.6. No ejecutes automáticamente acciones críticas.
• Tercera: muestra la transcripción/prompt y permite editar antes de generar; reduce re‑generaciones y costes.

4) Cómo combinar imagen generada con mock‑up realista

• Si tu IA devuelve fondo blanco: usa mix-blend-mode: multiply para integrar color y sombras.
• Para recortar a área imprimible: usa mask-image con PNG alfa que delimite el área.
• Para objetos 3D (tazas, gorras): renderiza textura en Three.js y proyecta. La imagen 2D se vuelve material.

5) Cache y coste: no es opcional

• Hash(prompt + constraints) → si existe en Redis, devuelve URL.
• TTL inteligente: alta prioridad evergreen (best sellers) tiene TTL largo; prompts únicos TTL corto.
• Rate limiting en BFF y quotas por usuario. Un mal prompt viral = factura.

6) Moderación y cumplimiento legal

• Antes de llamar al modelo: pass prompt through a moderation endpoint.
• Bloquea logos/trademark detectados y solicita versión con licencia o alternativa propuesta.
• Guarda hashes de audio/texto, no PII completo, salvo consentimiento.

7) Pipeline de prompts (versión como código)

No mezcles estilos. Versiona prompts. Cada cambio debe pasar CI.

Ejemplo de prompt system (simple y efectivo):

"UserPrompt: {{user}}. BrandRules: fondo blanco, sin texto, colores primarios: #000,#fff,#ff0066, estilo: vector elegante, resolución: 2048x2048. Output: return image url or base64."

Guarda promptId en la metadata de la imagen (para reproducibilidad).

8) Snippet Angular (esqueleto, revisa nombres)

• Usa Signals para estado: isLoading, imageUrl, error.
• Llama a BFF con debounce en input.
• Muestra preview inmediatamente si hay cache.

9) Casos límite y cómo protegerte

• Input malicioso: sanitize + moderate.
• Trafico súbito: circuit breaker en BFF con fallback a placeholder.
• Resultados pobres: ofrecer 3 variantes y un botón “regenerar” que cuente como 1 intento.

10) Métricas que importan (no te fijes en impresiones)

• Latencia end-to-end (ms).
• Cost per generation.
• Cache hit ratio.
• Conversion lift por producto con imagen generativa.
• Tasa de re‑generaciones por usuario.

Checklist mínimo antes de lanzar

• [ ] BFF con autenticación y rate limiting.
• [ ] Cache (Redis) por prompt hash.
• [ ] Moderación automática en BFF.
• [ ] Mock‑up pipeline (mask + blend + optional 3D).
• [ ] Observability y tracing (traceId en metadata).
• [ ] Tests e2e con fixtures de imágenes.
• [ ] Política de retención y GDPR (si almacenas diseños con PII).

Si quieres algo listo para pegar en tu repo Dime exactamente qué prefieres y te lo doy:

• “QUIERO EL REPO”: repo con Angular UI + BFF Node + Redis cache + prompts versionados + tests e2e.
• “QUIERO EL BFF”: solo el BFF con endpoints, moderación, cache y llamadas DALL‑E.
• “QUIERO LA UI”: Angular component con Signals, Canvas mock‑up y Three.js demo.

Esto no acaba aquí: si implementas mal, perderás dinero; si lo implementas bien, venderás productos que nadie espera. ¿Qué quieres construir primero — la fábrica (BFF) o la vitrina (UI)? Responde “BFF” o “UI” y te paso el plan con código listo para copiar y pegar.

Si buscas una continuación práctica y orientada a equipos que implementan pipelines, revisión de prompts y workflows de producción, considera explorar Dominicode Labs como recurso complementario. Ofrece experimentos y plantillas que encajan con la arquitectura y las pruebas operativas descritas en este artículo.

FAQ

• ¿Por qué necesito un BFF en este flujo?
• ¿Qué modelo debo usar en producción?
• ¿Cómo reduzco costes por generación?
• ¿Qué hago si aparece un logo o trademark?
• ¿Cómo debe integrarse la cache?
• ¿Qué métricas debo vigilar al lanzar?
• ¿Cuándo ofrecer regeneraciones y cómo limitar abusos?

¿Quieres dejar de ser el cuello de botella y convertirte en el mentor que realmente forma gente?

Tiempo estimado de lectura: 6 min

• La IA es potente para preparar material pedagógico; el mentor sigue siendo responsable de validar y acompañar.
• Usa prompts versionados, Katas con bugs intencionales y defensa oral para forzar pensamiento crítico.
• Estructura el mentoring en cuatro capas: objetivo, material personalizado, ejercicio práctico y validación humana.

¿Quieres dejar de ser el cuello de botella y convertirte en el mentor que realmente forma gente? Perfecto. Porque la IA te lo pone fácil —si sabes usarla— y también te lo deja todo más caro si lo haces mal.

Poca gente habla de esto: la IA no va a sustituir a los docentes técnicos buenos. Los va a desnudar. Los malos quedarán expuestos. Los buenos escalarán su enseñanza como nunca. Descubrí algo curioso: con unos prompts bien pensados puedes preparar una lección que normalmente te llevaría horas, en 10 minutos. Y el desarrollador la absorbe mejor. Pero hay truco. No es darle la lección a la IA y olvidarte. Es usarla como motor pedagógico y seguir caminando junto al alumno.

Resumen rápido (lectores con prisa)

La IA funciona como herramienta de preparación pedagógica: genera explicaciones, ejercicios y ejemplos adaptados al stack. Úsala cuando necesites escalar material o crear Katas repetibles, pero siempre valida con interacción humana. La secuencia recomendada: define objetivo de aprendizaje, genera material personalizado, diseña ejercicio práctico y realiza validación 1:1. Versiona los prompts y obliga defensa oral y tests escritos para evitar atrofia del pensamiento crítico.

Primero: qué hace bien la IA (y qué no)

• Bien: diseña explicaciones, genera ejercicios adaptados al stack, crea ejemplos y casos de estudio, monta Katas con bugs intencionados.
• Mal: reemplazar la empatía, entender la política interna de tu arquitectura, o garantizar que el talento del dev se forme por sí solo.
• Resultado real: la IA es tu guionista. Tú sigues siendo el director.

Regla de oro: la IA prepara. Tú validas. Tú acompañas.

Cómo estructurar tu mentoring con IA (4 capas)

1. Definir objetivo de aprendizaje (qué debe saber el dev al final).
2. Generar material personalizado con IA (explicaciones + analogías + ejemplos).
3. Diseñar ejercicio práctico y lab (Kata con bug).
4. Validación humana: 1:1 donde el dev explica y demuestra.

Si te saltas la validación, lo único que escalas es ilusión.

Gancho pedagógico: analogías que conectan

Un dev entiende más rápido con una buena metáfora. Pide a la IA analogías específicas y concretas, no genéricas.

Prompt práctico

“Actúa como Staff Engineer. Explica Angular Signals a un junior con ejemplos prácticos. Usa la analogía de una hoja de cálculo para contrastar Signals vs RxJS (BehaviorSubject). Muestra un ‘antes’ con RxJS y un ‘después’ con Signals, y finaliza con 2 casos donde Signals reduce re-rendering.”

¿Por qué funciona? Porque la hoja de cálculo es algo que todo el mundo visualiza. La analogía baja el umbral cognitivo y acelera la comprensión.

Katas: el arma secreta para formar sin microgestionar

Los Katas con errores intencionales enseñan mejor que 100 lecturas de docs. La IA puede generar ejercicios que replican problemas reales en tu stack.

Prompt plantilla para Kata

“Genera un componente React + TypeScript que simule un carrito. Introduce un bug sutil de ‘stale closure’ en useEffect y un problema de re-rendering. Devuélveme: 1) el código base, 2) 3 pistas progresivas, 3) 2 test-cases que deben fallar antes de arreglar.”

Implementación práctica

• Entrega el Kata al junior.
• Pistas sólo si lo piden (no antes).
• En la 1:1, pídele que explique por qué ese bug ocurre y que proponga dos soluciones.
• Resultado: aprende a razonar, no a copiar.

Enseñar arquitectura: casos de estudio progresivos

No expliques CQRS con diagramas abstractos. Crea una historia que evolucione con la empresa.

Prompt plantilla

“Genera un caso de estudio: e-commerce monolítico que colapsa en Black Friday. Describe cómo extraer ‘Inventario’ a microservicio con Kafka. Explica beneficios, nuevas complejidades (consistencia eventual) y checklist de rollout.”

Cómo usarlo:

• Léele el caso al mid-level.
• Pídele que proponga dos alternativas (monolito modular vs microservicio) con pros/cons.
• Debate 15 minutos.
• Tarea: diseñar contrato de API y tests de integración para el nuevo servicio.

Evita la atrofia del pensamiento crítico

Peor que no enseñar es permitir que el dev se apoye en Copilot/ChatGPT para resolver tu Kata. Entonces no aprendió nada. Tu métrica no es “funciona”, es “puedes explicarlo”.

Reglas de control

• Todo ejercicio debe terminar con defensa oral: el dev explica la solución en 1:1 y responde “¿qué pasa si…?” tres veces.
• Obliga a escribir tests que prueben los casos límite que la IA no pensó.
• Penaliza respuestas copiadas: si el dev no puede justificar, regresa el ejercicio.

Plantillas de prompts listos para usar

1) Explicación pedagógica (concepto nuevo)

System: “Eres un Staff Engineer que sabe enseñar.”

User: “Explícame [concepto] a un junior. Usa una analogía simple y un ejemplo mínimo en [stack]. Da 2 preguntas de comprobación y 1 mini-ejercicio.”

2) Kata con bug intencional

System: “Actúa como instructor de bootcamp.”

User: “Crea un kata en [stack] que simule X problema. Incluye código con el bug, 3 pistas y 2 test cases que deben fallar.”

3) Caso de estudio arquitectónico

System: “Eres un arquitecto pragmático.”

User: “Genera un caso de estudio: problema, soluciones posibles, trade-offs, checklist de rollout y métricas a vigilar.”

Validación técnica: no confíes ciegamente

La IA alucina. Especialmente con APIs nuevas. Siempre ejecuta y compila el ejemplo. Si vas a enseñar Angular Signals o Server Actions, valida primero.

Checklist de pre-entrega

• El código compila.
• Los test-cases se ejecutan y fallan donde deben.
• La analogía no distorsiona el concepto principal.
• No hay promesas falsas sobre compatibilidad.

Cómo convertir cada sesión en aprendizaje medible

No dejes que la sesión sea nota mental. Traduce en artefactos.

Después de cada 1:1 o Kata:

• Crea un pequeño ticket con la tarea de seguimiento (1–2 subtareas).
• Define métricas simples: tests añadidos, tiempo para arreglar, porcentaje de explicación correcta.
• Revisa en 2 semanas. Si no hay progreso, cambia el enfoque de mentoring.

Ejemplo concreto: “Explain Angular Signals”

(Usa esto con tu junior)

Prompt:

“Actúa como Staff Engineer. Explica Angular Signals a un junior con ejemplos prácticos. Usa la analogía de una hoja de cálculo. Muestra cómo sería con RxJS y cómo mejora con Signals. Da 3 preguntas de comprobación y un mini-kata.”

Entrega esperada del modelo:

• Analogía clara.
• Código ‘antes’ y ‘después’.
• Tres preguntas que obligan al dev a pensar.
• Un kata mini (5–10 líneas) para practicar.

Lo que haces tú después:

• Revisa la explicación.
• Pide al dev que la replique sin mirar.
• Si falla, repites el kata con otra analogía.

Cultura: transforma la dependencia en competencia

No se trata de prohibir la IA. Se trata de convertirla en herramienta de aprendizaje.

Políticas que funcionan

• Todo código asistido por IA viene con un párrafo: “¿Por qué esto resuelve el problema?” Si no existe, no se mergea.
• Prompt registry en la wiki: guarda prompts usados para Katas y explicaciones. Auditoría futura.
• Sesión semanal de 30 minutos: “Explain why this code sucks” — donde un dev explica por qué otra implementación es mala.

Errores que vas a ver (y cómo evitarlos)

• Error: el junior copia la solución y pasa el Kata. Solución: defensa oral + tests que el dev debe escribir.
• Error: la IA mezcla versiones de API. Solución: siempre ejecutar y validar.
• Error: confiar la formación solo a la IA. Solución: la IA prepara. Tú acompañas. Siempre.

Cierre con acción (porque esto no acaba aquí)

La IA te hace eficiente. Pero el talento se forma caminando juntos. Si quieres que te facilite el trabajo, tengo un kit listo: 10 prompts versionados para explicar conceptos, 5 Katas adaptadas a React/Node/Angular y una plantilla de 1:1 que fuerza la defensa técnica.

Di “QUIERO EL KIT” y te lo envío en 10 minutos. O pega aquí el concepto que tienes que explicar mañana y te preparo la sesión con analogía, código y Kata listo para usar.

No lo dejes en “algún día”. Si sigues esperando, tu equipo seguirá copiando soluciones que no entiende. Y entonces sí: la IA habrá acelerado la mediocridad. ¿Qué prefieres construir: gente que copia o gente que piensa? Yo sé la respuesta. ¿Tú?

Dominicode Labs (mención)

Si estás trabajando con automatización, agentes o workflows y buscas ejemplos prácticos y experimentos aplicados, puedes seguir explorando recursos y experimentos en Dominicode Labs. Es una continuación lógica para equipos que quieren sistematizar prompts, Katas y pipelines de validación técnica.

FAQ

• ¿La IA puede sustituir al mentor técnico?
• ¿Qué es un Kata con bug intencional y por qué funciona?
• ¿Cómo evito que los devs copien la solución de la IA?
• ¿Con qué frecuencia debo versionar mis prompts?
• ¿Qué incluye la checklist de pre-entrega?
• ¿Qué métricas simples puedo usar para medir progreso?

¿La IA puede sustituir al mentor técnico?

No. La IA prepara material y escala explicaciones, pero no reemplaza la validación humana, la empatía ni la comprensión de la política interna de una arquitectura. El mentor sigue siendo responsable de acompañar y evaluar.

¿Qué es un Kata con bug intencional y por qué funciona?

Es un ejercicio con un fallo deliberado que reproduce un problema real del stack. Funciona porque obliga al dev a razonar sobre causa-efecto, escribir tests y defender la solución en una 1:1, en lugar de copiar una solución aparentemente “correcta”.

¿Cómo evito que los devs copien la solución de la IA?

Reglas: defensa oral obligatoria, escribir tests que cubran casos límite y penalizar soluciones sin explicación. Las pistas del Kata deben entregarse sólo bajo demanda.

¿Con qué frecuencia debo versionar mis prompts?

Versiona cuando el kata funcione mejor o cuando la explicación suene rara. No hay un ritmo fijo: versiona según resultados y feedback del alumno.

¿Qué incluye la checklist de pre-entrega?

Los ítems clave: el código compila, los tests fallan donde deben, la analogía no distorsiona el concepto y no hay promesas falsas sobre compatibilidad.

¿Qué métricas simples puedo usar para medir progreso?

Ejemplos prácticos: tests añadidos, tiempo para arreglar, porcentaje de explicación correcta en la defensa oral y seguimiento en 2 semanas.