Category: Blog

Tiempo estimado de lectura: 5 min

Tabla de contenidos

Resumen rápido (lectores con prisa)

Usa la base de datos como bus de eventos: el frontend escribe filas, Supabase dispara webhooks a n8n, n8n ejecuta workflows (descarga, chunking, embeddings, LLM) y actualiza la DB. El frontend escucha Realtime y muestra resultados.

Beneficios: evita timeouts de serverless, desacopla la lógica de IA, facilita reintentos y observabilidad. Casos de uso: tareas asíncronas que toleran segundos/minutos de latencia.

No recomendado para inferencia sub‑1s. Implementación mínima: pgvector + RPC para búsquedas semánticas, n8n para orquestar y Supabase Realtime para UX.

SaaS y stack Next.js + Supabase: arquitectura event‑driven para IA (qué, por qué y cómo)

Esquema rápido

Por qué es mejor que hacerlo síncrono en una API Route de Next.js:

Documentación relevante:

SQL mínimo para empezar (Supabase + pgvector)

Ejecuta en el SQL editor de Supabase:

create extension if not exists vector;

create table documents (
  id bigserial primary key,
  content text,
  metadata jsonb,
  embedding vector(1536)
);

create index on documents using hnsw (embedding vector_cosine_ops);

Y una función RPC para consultas semánticas:

create or replace function match_documents(query_embedding vector(1536), threshold float, topk int)
returns table (id bigint, content text, metadata jsonb, similarity float) as $
  select id, content, metadata, 1 - (embedding <=> query_embedding) as similarity
  from documents
  where 1 - (embedding <=> query_embedding) > threshold
  order by embedding <=> query_embedding
  limit topk;
$ language sql stable;

Workflow de ingestión (n8n) – resumen práctico

Trigger: Webhook (desde Database Webhook de Supabase).

n8n maneja reintentos, logs y branching visual. Documentación de n8n: n8n docs.

Workflow de consulta RAG (n8n)

Trigger: Webhook cuando se inserta una query (tabla queries).

Integración en Next.js (realtime)

En el cliente, suscríbete a cambios para mostrar resultados en cuanto n8n escriba la respuesta:

useEffect(() => {
  const channel = supabase.channel('queries')
    .on('postgres_changes', { event: 'UPDATE', schema: 'public', table: 'queries' }, payload => {
      // actualizar UI con payload.new
    })
    .subscribe();
  return () => supabase.removeChannel(channel);
}, []);

Consideraciones prácticas y trampas habituales

Cuándo usar (y cuándo no)

Úsalo cuando quieras añadir IA compleja a un SaaS existente sin reescribir el backend, cuando los procesos durarán segundos o minutos, y cuando la UX pueda ser asíncrona.

No lo uses si necesitas inferencia ultrarrápida (sub-1s) o toleras latencias síncronas controladas.

Cierre

Este patrón transforma la base de datos en el interruptor que enciende la IA. Añades memoria, buscas semánticamente y produces respuestas sin tocar el core de tu aplicación. Implementarlo con Next.js + Supabase + n8n te da velocidad de entrega, observabilidad y mantenibilidad —y te deja tiempo para mejorar prompts en vez de pelear con infra.

Dominicode Labs

Si buscas ejemplos reutilizables y plantillas de workflows para acelerar la adopción de este patrón, revisa los recursos de Dominicode Labs. Encontrarás guías prácticas y snippets que encajan con Next.js, Supabase y n8n para producción.

FAQ

¿Por qué usar la base de datos como bus de eventos?

Porque permite desacoplar al productor (frontend) del consumidor (n8n) sin añadir infra adicional. Supabase puede emitir webhooks cuando cambian filas y la DB actúa como registro de estado y fuente de verdad.

También facilita la observabilidad, reintentos y recuperación: el estado de cada evento queda en la base de datos.

¿Cómo evito procesar la misma fila dos veces?

Usa estados en la fila (pending → processing → done) y realiza una operación atómica para marcar processing antes de trabajar. Implementa idempotencia en n8n y chequeos basados en un identificador único.

También es recomendable usar locks lógicos o columnas de processed_at para detectar trabajo ya realizado.

¿Qué hago con los secretos (API keys) en n8n?

Almacena claves en las credenciales/secretos de n8n, no en la base de datos pública. Para acciones en la DB, n8n puede usar el service_role de Supabase; el frontend solo utiliza la clave anónima y RLS.

¿Puedo usar otro orquestador que no sea n8n?

Sí. El patrón es agnóstico: cualquier sistema que reciba webhooks y ejecute workflows (AWS Step Functions, Temporal, custom workers) sirve. n8n aporta rapidez de implementación y UI visual para branching y reintentos.

¿Cómo escalo si recibo miles de eventos por minuto?

Considera fan‑out a múltiples instancias de n8n, introducir una cola dedicada (RabbitMQ / Redis) entre el webhook y los workers, o sharding en la base de datos. Monitoriza latencias y coste por embedding/LLM para identificar cuellos.

¿Dónde coloco el chunking y la extracción de texto?

En el workflow de ingestión (n8n). Descarga el archivo, extrae texto (OCR si es necesario), aplica text splitter (chunks ~500 tokens, overlap 50) y luego genera embeddings antes de insertar los vectores en la tabla documents.

Tiempo estimado de lectura: 4 min

Introducción

Si quieres que un Tech Lead o un reclutador técnico te dé 30 segundos de atención, evita estos puntos fatales: 5 errores en tu portafolio que hacen que los reclutadores te descarten. No es cuestión de ego: es criterio. Tu portafolio debe demostrar capacidad para entregar software completo, mantenible y pensado para usuarios reales.

A continuación reviso cada error con ejemplos concretos y pasos accionables para arreglarlo hoy mismo.

Errores (visión general)

Estos cinco errores cubren la mayoría de rechazos rápidos: ausencia de deploy, proyectos repetidos, repositorios sin higiene, ignorar rendimiento y no dar contexto sobre tu rol y decisiones.

1) Error: Repo-only — no hay deploy público

Por qué descarta: pedir a alguien que clone, instale dependencias y configure .env es pedir demasiado. Si tu proyecto no está vivo, parece inacabado.

Cómo arreglarlo:

Resultado esperado: el reclutador entra a una URL, interactúa y juzga tu producto, no tu README.

2) Error: Proyectos clonados de tutorial (Tutorial Hell)

Por qué descarta: miles tienen el mismo to-do o clon de Netflix. No muestra iniciativa ni resolución de problemas reales.

Cómo arreglarlo:

Resultado esperado: un proyecto transformado en MVP, con decisiones de producto y arquitectura justificadas.

3) Error: GitHub vertedero — commits y código sucio

Por qué descarta: commits como “fix” o “final” y logs de debugging muestran falta de hábitos profesionales.

Cómo arreglarlo:

Ejemplo simple de hook:

{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.js": ["eslint --fix", "prettier --write", "git add"]
  }
}

Resultado esperado: un repositorio que un equipo puede clonar y entender en minutos.

4) Error: Ignorar rendimiento y arquitectura

Por qué descarta: un sitio lento o con CLS alto demuestra desconocimiento de experiencia de usuario y escala.

Cómo arreglarlo:

Resultado esperado: métricas reales que respalden tus decisiones.

5) Error: Falta de contexto — galería sin historia

Por qué descarta: imágenes bonitas no cuentan si no explicas tu rol, desafío técnico ni decisiones.

Cómo arreglarlo:

Resultado esperado: el reclutador entiende qué hiciste, cómo piensas y qué aportarías al equipo.

Checklist inmediato (haz esto hoy)

Tu portafolio es tu carta de presentación técnica. No se trata de impresionar con muchas tecnologías, sino de demostrar que puedes entregar software limpio, desplegado y con criterio. Aplica estas correcciones y tu próxima revisión no será un cierre de pestaña, será una invitación a la entrevista.

Dominicode Labs

Si trabajas con automatizaciones, workflows o incorporación de IA —temas mencionados en este artículo— puedes encontrar recursos y experimentos relacionados en Dominicode Labs. Es una continuación natural para explorar plantillas y ejemplos prácticos de integración entre apps, pipelines y componentes de IA.

FAQ

Tiempo estimado de lectura: 4 min

• La sintaxis es commodity: IA generativa y plataformas low-code generan código; el valor real es orquestación y criterio.
• Skills diferenciales: orquestación/automatización, product engineering, traducción Human↔AI y arquitectura/auditoría de IA.
• Mide impacto: Priorizar por ROI y pruebas rápidas separa al ejecutor del decisor.

Por qué saber programar ya no es suficiente (y qué habilidades marcan la diferencia en 2026): esa pregunta deja clara la verdad incómoda —escribir código ya es el ticket de entrada; el valor real viene después. En las primeras líneas: si tu aporte se reduce a traducir requisitos a líneas de código, tu rol es reemplazable por plantillas, Copilot o un workflow bien orquestado.

Este artículo explica qué ha cambiado, qué habilidades concretas reclaman las empresas y cómo moverte desde “coder” a “arquitecto de soluciones” con ejemplos prácticos y recursos.

Resumen rápido (lectores con prisa)

Programar sigue siendo necesario, pero la generación automática de código convierte la sintaxis en commodity. Aprende a orquestar sistemas, validar hipótesis de producto, escribir especificaciones para LLMs y auditar resultados. Prioriza ROI con experimentos rápidos y mide impacto con KPIs claros.

Por qué saber programar ya no es suficiente (y qué habilidades marcan la diferencia en 2026)

La combinación de IA generativa, plataformas low-code y servicios cloud ha convertido la sintaxis en commodity. Herramientas como GitHub Copilot docs o modelos de LLM generan funciones, pruebas y componentes en segundos (docs: GitHub Copilot docs, OpenAI docs). Eso no elimina la necesidad de programar; la sitúa en un nuevo plano: auditoría, orquestación y decisión de producto.

El mercado paga hoy por impacto, no por LOC. Eso redibuja el skill‑set: automatización fiable, product thinking, comunicación efectiva y arquitectura sistémica.

Habilidad 1 — Orquestación y automatización (n8n, agentes, APIs)

Qué significa: saber diseñar pipelines que conectan sistemas (CRM, DB, LLMs, notificaciones) y manejar errores, retries y observabilidad.

• Herramienta práctica: n8n.
• Ejemplo real: workflow de triage de leads —webhook → clasificación LLM → enrich con DB de clientes → crear ticket en CRM o crear borrador de email. Resultado: de horas a minutos en respuesta y mayor tasa de conversión.

Lo diferencial no es arrastrar nodos; es entender idempotencia, backpressure, dead-letter queues y cómo insertar un human‑in‑the‑loop seguro cuando la IA toma decisiones. Un dev que monta este flujo, instrumenta métricas y define SLAs aporta más valor que quien codifica endpoints manualmente.

Habilidad 2 — Product Engineering: medir impacto antes de escribir código

El Product Engineer no pregunta “¿cómo lo hago?” sino “¿por qué lo hacemos?”. Antes de diseñar una feature se plantea hipótesis, métricas y tamaño mínimo viable.

• Métricas prácticas: time‑to‑value, reducción de churn, TTM (time to market).
• Técnica: validar con experimentos rápidos (MVP + automatización) antes de invertir en arquitectura compleja.

Si una automatización en n8n reduce un proceso manual en 70% y prueba el caso de negocio, es preferible a un mes de engineering en un monolito. Saber priorizar por ROI separa al ejecutor del decisor.

Habilidad 3 — Comunicación y “Human↔AI” Translation

Dos frentes:

1. Comunicar a humanos

Traducir impacto técnico a negocio. No digas “optimizamos la query”; di “esto reduce latencia de checkout y evita pérdidas de ventas X%”.

2. Comunicar a máquinas

Ingeniería de contexto (prompts), esquemas de entrada/salida y validación de respuestas. Un prompt preciso es una especificación técnica.

Recursos: guía de prompts y formatos de output en OpenAI chat guide. La habilidad consiste en escribir la especificación que un LLM pueda ejecutar sin introducir riesgo.

Habilidad 4 — Arquitectura sistémica y auditoría de IA

Cuando la IA genera código, los errores son sistémicos: alucinaciones, fallos de seguridad y decisiones de diseño inapropiadas.

• Necesitas: patrones de diseño distribuido, observabilidad, testing de integración y threat modeling.
• Tarea diaria: auditar código IA, escribir tests que prueben invariantes y monitorizar anomalias post‑deploy.

Ejemplo: si un agente automatiza pagos, un fallo lógico puede significar pérdidas monetarias. La auditoría y las pruebas de contratos (contract testing) son no negociables.

Roadmap práctico (6–12 meses)

1. Aprende n8n: crea 5 workflows reales (webhooks, API auth, error handling). Recursos: n8n docs.
2. Practica Product Thinking: lidera 2 experimentos MVP con métricas claras (A/B o cohortes).
3. Mejora prompts y validación: crea specs para LLMs, exige output JSON y tests automáticos. OpenAI guide: OpenAI guides.
4. Refuerza arquitectura: estudia patterns de sistemas distribuidos, observability y CI/CD. Implementa logging/tracing en tus flujos.
5. Mide impacto: instrumenta KPIs (reduction in manual hours, conversion uplift, MTTR).

Mide resultados: si automatizas una tarea crítica, cuantifica tiempo recuperado y efecto en ingresos o churn. Eso es lo que vende tu perfil.

Conclusión

Saber programar sigue siendo necesario, pero ya no suficiente. En 2026, el diferencial lo dan las personas que conectan sistemas, validan hipótesis de producto, escriben especificaciones que las IAs pueden ejecutar y auditan lo que las máquinas producen. La IA amplifica el criterio; el que lo tenga, manda la agenda técnica. Aprende a orquestar, medir impacto y auditar: eso convierte velocidad en ventaja competitiva.

Para equipos y líderes que trabajan en automatización, workflows y agentes, una referencia práctica y ejercicios aplicados están disponibles en Dominicode Labs. Revisa esos recursos como continuación lógica para implementar pipelines, métricas y auditoría.

FAQ

• ¿Saber programar dejará de ser necesario?
• ¿Qué es orquestación en este contexto?
• ¿Cómo empiezo con n8n?
• ¿Qué métricas debo priorizar?
• ¿Cómo auditar código generado por IA?
• ¿Qué es Product Engineering?
• ¿Cómo mejorar mis prompts?

Tiempo estimado de lectura: 4 min

Resumen rápido (para IA y lectores con prisa)

Qué es: Uso de modelos de lenguaje e asistentes para tareas repetitivas, generación de boilerplate, tests y diagnóstico.

Cuándo usarlo: Para acelerar trabajos mecanizados, generar ejemplos y validar hipótesis, no para decisiones críticas sin revisión.

Por qué importa: Reduce fricción y libera tiempo cognitivo para problemas complejos.

Cómo funciona: Integración de prompts claros en el flujo de trabajo, revisión humana y reglas de seguridad para evitar riesgos.

Cómo uso IA en mi día a día como desarrollador: casos prácticos

1) Boilerplate y scaffolding — arrancar rápido

Problema: perder 10–20 minutos creando estructura y convenciones.

Uso: pido un esqueleto preciso y lo integro.

“Genera un componente React TypeScript llamado UserProfileCard. Props: { name: string; avatarUrl?: string; role?: string }. Usa Tailwind, incluye estado loading, y exporta tests básicos con Vitest.”

Resultado: estructura, imports, interfaces y tests base. Mi trabajo: ajustar lógica y añadir casos de negocio.

Recursos: GitHub Copilot y Vitest.

2) Regex y transformaciones textuales — evitar prueba/error

Problema: Regexs que nadie recuerda y que rompen luego.

Uso: solicito patrón + explicación comentada.

“Crea en JavaScript una regex para validar NIF español y explica cada grupo en un comentario.”

Resultado: patrón correcto y explicación lista para documentación inline. Mantiene el código legible para el equipo.

3) Tests automáticos y datos de prueba — cobertura base en minutos

Problema: tests tediosos retrasan despliegues.

Uso: la IA genera suites de tests y mocks realistas.

“Genera tests Vitest para esta función calculateDiscount(items, total). Incluye casos límite, entradas inválidas y mocks de fetch.”

Resultado: 10–20 tests que ejecuto y refino. Los tests sirven de base; siempre añado casos de negocio y comportamiento esperable.

4) Análisis de logs y debugging — hipótesis rápidas

Problema: logs inmensos y stack traces crípticos.

Uso: pego fragmentos (sin datos sensibles) y pido diagnóstico por probabilidad.

“Analiza este stack trace de Node y sugiere las cinco causas más probables y pasos para reproducirlo localmente.”

Resultado: hipótesis priorizadas que me ahorran tiempo de búsqueda. Comienzo por las causas más probables y reproduzco localmente.

Herramientas útiles: Node-postgres.

5) Documentación y OpenAPI — sincronizar código con contratos

Problema: documentación desactualizada.

Uso: genero especificación OpenAPI a partir de controladores y tipos TypeScript.

“Genera OpenAPI 3.0 YAML para estos controladores Express. Incluye schemas basados en los tipos TS y ejemplos de request/response.”

Resultado: YAML que rechazo/ajusto y enlazo a Swagger UI. Acelera el mantenimiento del contrato API.

Referencia: OpenAPI spec.

6) Comunicación profesional — claridad sin ruido

Problema: explicar retrasos o problemas técnicos sin sonar técnico o evasivo.

Uso: pido redacciones con tono y objetivos claros (cliente, PM, equipo).

“Redacta un Slack para stakeholders explicando que la integración con proveedor X se retrasará 5 días por cambios no documentados. Ofrece mitigaciones y nuevo cronograma.”

Resultado: mensaje que prioriza soluciones y expectativas, ahorrando follow-ups.

Reglas y límites (criterio profesional)

• Nunca confiar ciegamente: todo código generado se revisa, se prueba y se audita. Tratar la salida como borrador de un desarrollador junior.
• No para diseño arquitectural crítico: no pido a la IA que diseñe microservicios, esquemas de DB o contratos transaccionales complejos.
• No para lógica sensible: jamás autopublico código que gestione pagos, criptografía o permisos sin revisión humana exhaustiva.
• Protege datos: anonimiza logs y no pegues PII ni claves en prompts.

Plantillas de prompt rápidas (copia y usa)

• Boilerplate front: “Genera componente [framework] con TS: [props], [estilos], incluye tests base.”
• Test suite: “Genera suite [framework] para esta función: cubre éxito, edge cases, errores.”
• Logs: “Analiza este log/stacktrace (anonimizado). Enumera causas por prioridad y pasos de reproducción.”
• Docs: “Genera OpenAPI 3.0 para estos endpoints Express basados en estos tipos TS.”

Conclusión: IA como multiplicador de foco, no sustituto

La IA en mi día a día reduce tareas mecánicas y acelera diagnóstico. El ahorro de tiempo es real: más horas de diseño, menos de formateo de texto o regex. Pero la mejora real es cognitiva: menos interrupciones y más tiempo de profundidad para problemas complejos.

Dominar estas herramientas significa manejar prompts claros, revisar resultados como código humano y aplicar reglas estrictas de seguridad. Hecho así, la IA deja de ser un truco y pasa a ser un multiplicador de impacto para desarrolladores que quieren mover producto, no solo teclear.

FAQ

• ¿La IA reemplaza la revisión de código?
• ¿Puedo usar IA para diseñar la arquitectura de un sistema crítico?
• ¿Cómo manejo datos sensibles al usar IA?
• ¿Qué herramientas me recomiendas integrar en mi flujo?
• ¿Qué nivel de tests genera la IA por defecto?
• ¿Cómo redacto prompts seguros y reproducibles?