Recurso del reel «La IA ya programa por ti» · 18 sep 2026
Lo que construyes con IA funciona. Estos 21 conceptos hacen que aguante.
En el video pasaron en menos de seis segundos. Aquí va cada uno sin jerga: qué es, qué
suele hacer mal el código que te escribe la IA cuando tú no lo conoces, y la frase exacta para
pedírselo bien. No tienes que dominarlos. Tienes que reconocerlos, porque la IA sólo construye lo que
sabes pedir.
Así se ven en el video. Cada tarjeta de aquí abajo lleva el mismo símbolo. Desliza →
Los 21, de un vistazo
Toca uno y te lleva a su ficha
Van en el orden del video y agrupados por el problema que resuelven. Cada uno lleva el
mismo símbolo que viste en pantalla: el logo oficial cuando la tecnología tiene uno, y un
símbolo nuestro cuando es una idea y no un producto.
Si no sabes que existe la inyección SQL, nunca vas a pedir que la prevenga. Cada concepto de esta
guía es una palabra que, dicha en el prompt, cambia el código que recibes.
Demo no es producción
Que funcione en tu compu no es que esté listo
En tu computadora sólo entras tú. En internet entran desconocidos, bots que prueban contraseñas
y servicios que te cobran por uso. Casi todos estos 21 existen por esa diferencia.
No es para memorizar
Reconocerlos basta
No necesitas saber programar un límite de peticiones. Necesitas saber que existe, qué problema
resuelve y cuándo pedirlo. La IA escribe la implementación; tú decides qué se construye y lo
revisas.
Grupo A · Lo tuyo · 01–03
Tu código y tus llaves
Lo primero que se rompe cuando trabajas con IA no es la app: es lo que la rodea. Un
cambio que no puedes deshacer, una contraseña escrita dentro del código, una llave que alguien más usa
con tu tarjeta. Los tres se resuelven el primer día y cuestan cero pesos.
01 Git
Desde el día uno
El historial de tu proyecto: cada cambio guardado con fecha y motivo, para poder
regresar a cualquier punto como si fuera un control Z que no se acaba.
Lo que pasa si no lo usas
La IA puede reescribir diez archivos en un segundo. Sin Git, si algo deja de funcionar no hay forma de
volver a como estaba hace una hora. Con Git es un comando.
Qué pedirle a la IA
«Inicializa Git en este proyecto, crea un .gitignore para mi stack y haz un
commit antes de cada cambio grande que me propongas.»
Los cuatro que vas a usar diario
git init # una vez por proyecto
git add . && git commit -m "ya funciona el login" # un punto de regreso
git log --oneline # la lista de tus puntos de regreso
git restore . # descarta lo que cambió desde el último commit
Los valores que tu app lee del sistema y no del código: contraseñas, llaves y
direcciones que cambian entre tu computadora y el servidor. En tu compu viven en un archivo
.env que nunca se sube.
Lo que suele hacer la IA
Pega la contraseña de la base de datos o la llave de OpenAI directo en el código «para que
funcione». Si ese archivo llega a GitHub, la llave es pública.
Qué pedirle
«Mueve todas las llaves y contraseñas a variables de entorno, crea un .env.example
sin valores reales y agrega .env al .gitignore.»
Lo que suele salir
const openai = new OpenAI({
apiKey: "sk-proj-8Hq…" // ← la llave, escrita en el código
});
Lo que pides
# .env (se queda en tu compu)
OPENAI_API_KEY=sk-proj-…
// el código sólo la lee
const openai = new OpenAI({
apiKey: process.env.OPENAI_API_KEY
});
La contraseña que usa tu app para hablar con otro servicio: OpenAI, Stripe, Google Maps.
Quien la tenga, gasta a tu nombre.
Lo que suele hacer la IA
Llama a la API desde el navegador con la llave adentro. Cualquiera que abra las herramientas de
desarrollador de su navegador la copia en diez segundos.
Qué pedirle
«Las llamadas con llave van en el servidor, nunca en el frontend. Crea un endpoint propio que haga la
llamada.» Y en el panel del proveedor: límite de gasto y una llave distinta por proyecto.
Si ya se subió
Dala por robada aunque haya estado un minuto. Revócala y crea otra: borrar el commit no la borra de
las copias ni del historial.
Son dos preguntas distintas y la IA suele contestar sólo la primera. Autenticación
comprueba quién entra; autorización decide qué puede hacer una vez adentro. RBAC y ABAC son dos formas
de escribir las reglas de la segunda.
LlegaUna petición
«Quiero ver el pedido 102»
→
Puerta 1 · Autenticación¿Quién eres?
Contraseña, «Entrar con Google», código por correo. Si no pasa: 401
→
Puerta 2 · Autorización¿Puedes ver esto?
Las reglas: por rol (RBAC) o por atributos (ABAC). Si no pasa: 403
→
SaleEl pedido
Sólo si pasó las dos puertas
04 Autenticación
Antes de lanzar
Comprobar que alguien es quien dice ser: contraseña, «Entrar con Google», un código por
correo o una llave de acceso del teléfono.
Lo que suele hacer la IA
Te construye un login desde cero y guarda las contraseñas tal cual en la base de datos. El día que
alguien la vea, ve las contraseñas de todos.
Qué pedirle
«Usa un servicio de autenticación probado (Supabase Auth, Clerk, Auth0, Firebase) en vez de hacer uno.
Si guardas contraseñas, sólo con hash de contraseña (Argon2id o bcrypt), nunca en texto.»
Decidir qué puede hacer cada quien una vez que entró: que cada cliente vea sus pedidos
y no los de todos.
Lo que suele hacer la IA
Esconde el botón pero no protege el servidor. O busca el pedido por su número sin revisar de quién es:
cambias /pedidos/101 por /pedidos/102 en la barra de
direcciones y ves el pedido de otra persona.
Qué pedirle
«En cada ruta del servidor revisa que el usuario tenga permiso sobre ese registro, no sólo que
haya iniciado sesión.» Si usas Supabase: «activa Row Level Security en todas las tablas».
Las dos contestan lo mismo —¿puede hacer esto?— con distinta pregunta de fondo.
Casi todas las apps empiezan con roles y suman atributos cuando los roles se empiezan a multiplicar.
Concepto
Cómo decide
Ejemplo
Cuándo basta
07 RBAC
Por rol. Los permisos se le dan a un rol (admin, vendedor, cliente) y a cada persona se le
asigna uno.
El vendedor puede editar productos; el cliente sólo ve los suyos.
Casi siempre, al empezar. Pídele a la IA: «roles guardados en la base, revisados en el
servidor, en un solo lugar».
09 ABAC
Por atributos de la persona, del registro y del momento: sucursal, horario, estado del
pedido.
Un vendedor edita pedidos de su sucursal, sólo si no están pagados y en horario
laboral.
Cuando empiezas a inventar roles como «vendedor-norte-tarde». Ahí conviene pasar a reglas.
La señal de alarma de los dos es la misma: un if (usuario.email ===
'tu@correo.com') regado por el código. Funciona hasta que contratas a alguien. Fuentes:
NIST · RBAC y
NIST SP 800-162 · ABAC.
Grupo C · Blindaje · 06, 08, 10
Lo que no se ve hasta que alguien lo prueba
Tres defensas que la IA omite porque la app corre igual sin ellas. Aquí va lo que
suele salir junto a lo que conviene pedir.
06 SSL/TLS
Desde el día unohttps://
El candado del navegador. Cifra lo que viaja entre la persona y tu servidor para que
nadie en medio pueda leerlo ni cambiarlo. SSL es el nombre viejo; lo que se usa hoy es TLS.
Dónde se escapa
Casi todos los hostings ponen el candado solos en tu sitio. Lo que se escapa son las APIs propias o los
servicios internos que se quedaron en http://, y los certificados que nadie
renovó.
Qué pedirle
«Fuerza https en todo el sitio y en las APIs, y redirige cualquier petición http a https.»
Fuente: IETF · RFC 9846, TLS 1.3 (actualización de julio 2026 que reemplaza al RFC 8446 original; mismo protocolo, mismo número de versión) · rfc-editor.org/rfc/rfc9846
08 CORS
Antes de lanzar
La regla del navegador que decide qué otros sitios pueden leer las respuestas de tu
servidor. Es el error de «blocked by CORS policy» que tarde o temprano te sale en la consola.
Lo que suele hacer la IA
Cuando ve el error, lo «arregla» con un asterisco: le dice al navegador que cualquier sitio
puede leer tu API. El error desaparece y la puerta queda abierta.
Qué pedirle
«Permite sólo mi dominio en CORS, sin asterisco.» Y recuerda: CORS protege a tus usuarios en el
navegador, no a tu servidor. Tu API igual tiene que revisar quién llama.
El código lo puedes volver a pedir. Los datos de tus clientes, no. Estos dos cuidan
que tu base responda rápido y que cambie sin perder nada.
11 Caching (Redis)
Cuando crezcas
Guardar una respuesta que tarda en calcularse para entregarla al instante la siguiente
vez. Redis es la herramienta más conocida para eso: guarda los datos en memoria.
Lo que suele hacer la IA
Guarda sin fecha de caducidad y tus clientes ven precios de ayer. O guarda datos personales con una
llave compartida y un usuario termina viendo lo de otro.
Qué pedirle
«Guarda en caché [la consulta lenta] con caducidad de X minutos, bórrala cuando el dato cambie y nunca
mezcles datos de dos usuarios en la misma llave.»
Así se ve en Redis
SET precio:123 "499" EX 300 # guarda el precio y lo olvida solo en 300 s
GET precio:123 # la siguiente vez responde desde memoria
Los cambios a la estructura de tu base (tablas, columnas) guardados como archivos
numerados, para aplicarlos igual en tu compu y en producción, y poder revertirlos.
Lo que suele hacer la IA
Cambia la tabla directo en producción, o borra una columna «que ya no se usa» y con ella los datos
que tenía.
Qué pedirle
«Haz este cambio como una migración nueva, sin borrar datos, y dime cómo revertirla.»
El camino de cada cambio
Pídelo como migración, nunca editando la base a mano.
Léela antes de aplicarla: busca DROP, DELETE o TRUNCATE.
Aplícala primero en una copia de la base, no en la de tus clientes.
Respaldo antes de producción, siempre.
Aplícala en producción y guarda el archivo en Git junto al código.
Tu app no vive sola: le llegan avisos de pagos, la llaman otras apps y ahora también
la usan agentes de IA. Cuatro conceptos para esa conversación.
13 Webhooks
Antes de lanzar
Un aviso automático que otro servicio le manda a tu app cuando pasa algo: «se pagó»,
«llegó un mensaje». En vez de preguntar cada minuto, te avisan. Es el nodo Webhook de n8n.
Lo que suele hacer la IA
Acepta cualquier cosa que llegue a la dirección del webhook. Cualquiera que la descubra puede mandarte
un «se pagó» falso.
Qué pedirle
«Verifica la firma de cada webhook con el secreto del proveedor, responde rápido y guarda el id del
evento para no procesarlo dos veces.» Los proveedores reintentan: el mismo aviso puede llegar dos
veces.
La firma viene en un encabezado
Stripe-Signature: t=…,v1=… # pagos con Stripe
X-Hub-Signature-256: sha256=… # eventos de GitHub
# se recalcula con tu secreto; si no coincide, se rechaza
Un tope de cuántas peticiones acepta tu app por persona en cierto tiempo. Quien se pasa
recibe un «espera tantito»: el código 429 Too Many Requests.
Lo que suele hacer la IA
Ninguna ruta tiene tope. Un bot prueba mil contraseñas por minuto, o alguien llama en bucle a tu ruta
que usa una API de IA y la factura te llega a ti.
Qué pedirle
«Pon un límite de peticiones en el login y en cualquier ruta que llame a un servicio de pago: X por
minuto por usuario o IP, con respuesta 429.»
Un estándar abierto para conectar asistentes de IA con herramientas y datos: tu
calendario, tu base de datos, GitHub. Cada conexión es un «servidor MCP»; por eso se dice «los MCPs».
Lo anunció Anthropic en noviembre de 2024; desde diciembre de 2025 es un proyecto fundador de la
Agentic AI Foundation (bajo la Linux Foundation, con Anthropic, Block y OpenAI), así que ya no
depende de una sola empresa.
HostTu asistente
Claude, Cursor, ChatGPT
⇄
ProtocoloMCP
El mismo idioma para todas las conexiones
⇄
Servidor MCPUna herramienta
GitHub, Supabase, tu CRM
El riesgo
Un servidor MCP puede leer lo que le des y hacer acciones en tu nombre. Instalar uno de un repositorio
cualquiera es como instalar un programa de un desconocido. Y un documento puede traer instrucciones
escondidas que el asistente intente seguir.
Qué hacer
Usa los servidores oficiales de cada proveedor, dales el mínimo permiso (sólo lectura si te basta) y
pide confirmación antes de cualquier acción que borre, pague o publique.
Una sola puerta de entrada para todas las llamadas a tus servicios. Ahí se revisa quién
llama, cuántas veces y a qué servicio va, en vez de repetirlo en cada uno.
Cuándo sí
Cuando ya tienes varios servicios o una API pública, y cada uno empezó a tener su propio login y su
propio límite, distintos entre sí.
Cuándo todavía no
Con una sola app y una base de datos, un gateway es una pieza más que configurar y pagar. Si la IA te
lo propone el día uno, pregúntale qué problema resuelve hoy.
La frase más cara del desarrollo. Estos dos hacen que tu app funcione igual en
todos lados y que sepas cuánto te va a costar tenerla prendida.
17 Docker
Cuando crezcas
Empaqueta tu app con todo lo que necesita —la versión de Node o Python, las librerías,
el sistema— en un contenedor que corre igual en tu compu y en el servidor.
Lo que suele hacer la IA
Escribe COPY . . y mete tu .env —con todas tus
llaves— dentro de la imagen. Quien tenga la imagen, tiene tus llaves.
Qué pedirle
«Crea un Dockerfile con una versión fija de la imagen base y un .dockerignore
que deje fuera .env, .git y
node_modules.»
Dockerfile
FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]
Rentar servidores, bases de datos y almacenamiento a un proveedor en vez de tener tu
propia máquina: pides lo que necesitas cuando lo necesitas y pagas por lo que usas.
Lo que suele hacer la IA
Te arma una arquitectura de empresa grande para una app con diez usuarios, o deja recursos encendidos
que cobran por hora aunque nadie los use.
Qué pedirle
«Dame la forma más simple de desplegar esto con un presupuesto de X al mes, y cómo pongo una alerta de
gasto.» La alerta de gasto va antes que cualquier otra cosa.
Los tres más avanzados. No los necesitas para lanzar; los necesitas para entender qué
te propone la IA cuando dice «microservicios» o «arquitectura escalable», y para decirle que todavía no.
19 Sistemas distribuidos
Cuando crezcas
Tu app corriendo en varias máquinas que se coordinan por la red. Ganas capacidad, y a
cambio la red falla, los mensajes llegan tarde o dos veces y los relojes no coinciden.
Las dos preguntas que lo cambian todo
¿Qué pasa si este servicio no responde?
¿Qué pasa si el mismo mensaje llega dos veces?
La trampa
Partir una app pequeña en muchos servicios «para que escale». Cada llamada que antes era interna ahora
puede fallar por la red. Empieza con uno y divide cuando duela.
Ordenar el código en capas, de adentro hacia afuera: al centro las reglas de tu negocio,
afuera la base de datos, el framework y las pantallas. Lo de adentro no depende de lo de afuera.
Lo que suele hacer la IA
Mete todo en un archivo de dos mil líneas: la lógica del negocio mezclada con la base de datos y la
pantalla. Funciona, pero cada cambio rompe otra cosa.
Qué pedirle
«Separa las reglas del negocio de la base de datos y del framework: que puedan probarse sin
conectarse a nada.» Si mañana cambias de base de datos, las reglas no se tocan.
Casi nadie aprende estos conceptos en orden: los aprende cuando algo se rompe. Si ya te
pasó alguna de estas, aquí está cuál te faltaba.
«Me llegó una factura enorme de OpenAI y no fui yo»
Una llave expuesta y sin tope. Revócala hoy y crea otra (API Keys), mueve la
llamada al servidor y ponle límite de peticiones (Rate Limiting).
«La consola dice “blocked by CORS policy”»
Tu API no le dice al navegador qué sitios pueden leerla. Arréglalo con tu dominio, no con un
asterisco (CORS).
«Un cliente vio los datos de otro»
La ruta revisa que haya sesión pero no de quién es el registro. Es el error más común de todos
(Autorización).
«La IA cambió algo y ya no sé cómo regresarlo»
Sin puntos de regreso. Desde hoy, un commit antes de cada cambio grande (Git).
«En mi compu funciona y en el servidor no»
Casi siempre falta una variable de entorno en el servidor o la versión es otra
(Variables de entorno, Docker).
«Actualicé la base y se perdieron datos»
Un cambio directo, sin migración ni respaldo. Restaura el respaldo y a partir de ahí, todo cambio
como migración (Migraciones).
«Se pone lentísimo cuando entra más gente»
La misma consulta pesada se repite para cada persona. Primero mide cuál; luego guárdala en caché
(Caching) y revisa el diseño (Diseño de sistemas).
«Me llegan pagos que nadie hizo»
Tu webhook acepta avisos sin verificar la firma, o procesa el mismo aviso dos veces
(Webhooks).
La receta que más vale
El prompt que revisa tu proyecto con los 21
Pégalo en Claude Code, Cursor o cualquier asistente que pueda leer tu proyecto
completo. No cambia nada: te entrega una tabla con lo que está bien, lo que está a medias y lo que
falta, empezando por lo que te puede costar dinero.
Auditoría de los 21
Actúa como revisor de seguridad y arquitectura de este proyecto. Lee el código completo y
dime, para cada uno de estos 21 conceptos, cómo está resuelto:
Git · variables de entorno · API keys · autenticación · autorización · SSL/TLS · RBAC · CORS ·
ABAC · prevención de inyección SQL · caching · migraciones de base de datos · webhooks ·
rate limiting · MCP · API gateway · Docker · cloud · sistemas distribuidos · diseño de sistemas ·
arquitectura limpia.
Para cada uno, en una tabla:
1. Estado: ✅ bien · ⚠️ a medias · ❌ falta · — todavía no aplica
2. Dónde lo viste (archivo y línea)
3. El riesgo en una frase, sin jerga
4. El cambio mínimo para arreglarlo
Ordena la tabla de mayor a menor riesgo: primero lo que pueda costar dinero o exponer datos de
usuarios. No modifiques ningún archivo todavía: entrega la tabla y espera a que te diga cuál
arreglamos primero.
Tres recetas para después de la tabla
Una por los arreglos que casi siempre salen primero.
1 · Saca los secretos del código
Busca en todo el proyecto llaves, contraseñas, tokens y URLs con credenciales escritas en el
código. Muévelas a variables de entorno, crea un .env.example con los nombres pero sin valores,
confirma que .env está en .gitignore y dime cuáles de esas llaves estuvieron en algún commit
para que las revoque.
2 · Revisa los permisos ruta por ruta
Haz una lista de todas las rutas del servidor que leen, cambian o borran datos. Para cada
una dime: quién puede llamarla, si revisa que el registro pertenezca al usuario y qué pasaría si
alguien cambia el id en la URL. Luego corrige las que no revisan, una por una.
3 · Prepáralo para producción
Prepara este proyecto para producción: forzar https, CORS sólo para mi dominio, límite de
peticiones en el login y en las rutas que llaman a servicios de pago, verificación de firma en
los webhooks y los cambios de base de datos como migraciones. Explícame cada cambio en una
frase antes de hacerlo.
Si vas empezando
En qué orden aprenderlos
No en el orden del video. En el orden en que te van a hacer falta.
Antes de escribir una línea más · Lo tuyo
Git, variables de entorno y API keys.
Cuestan cero, se hacen en una tarde y evitan los dos desastres más caros: perder el trabajo y
regalar tu tarjeta.
Antes de que entre alguien que no seas tú · Tus usuarios
¿Mis reglas de negocio se pueden probar sin conectarse a la base?
El filtro
¿Esto es para ti?
Te sirve
Sí, si…
Ya construiste algo con Cursor, Claude Code, Lovable o Bolt y funciona.
Estás por meter usuarios reales, datos de clientes o cobros.
Te salió un error que no entiendes: CORS, 401, 403, 429.
Quieres saber qué pedirle a la IA en vez de aceptar lo primero que te da.
Todavía no
Espérate si…
Todavía no has construido nada, ni con IA. Primero haz una app sencilla; esto va después.
Buscas un curso de programación desde cero. Esto es un mapa, no un curso.
Tu proyecto ya tiene un equipo técnico: esto lo saben de memoria.
Fuentes y método
De dónde salió cada ficha
Cada definición se contrastó el 18 de septiembre de 2026 contra la documentación
oficial o el estándar que la define, no contra resúmenes. Estas son las principales.
Nota de método. Las definiciones son nuestra explicación en español de documentación oficial
que casi siempre está en inglés; no son citas textuales. Lo que dice «lo que suele hacer la IA» es
experiencia propia revisando código generado con IA, no una estadística. Los fragmentos de código son
ejemplos mínimos para reconocer el patrón, no código para copiar a producción. Los símbolos son los del
video: los logos oficiales de Git, dotenv, Redis, Docker y el Model Context Protocol, el ícono del nodo
Webhook de n8n, y símbolos propios para los conceptos que no tienen logo. Sotai no está afiliada a
ninguna de las marcas mencionadas.
Y ya
Empieza por los tres de hoy
No intentes los 21 esta semana. Haz Git, variables de entorno y API keys hoy; corre el
prompt de auditoría mañana y arregla lo que salga en rojo. Si tu app ya tiene clientes y prefieres que
alguien revise los 21 contigo antes de que un error te cueste, mándanos un DM: construir software que
aguante gente de verdad es justo lo que hacemos.
