¿Qué aprender en 2026 si ya sabes desarrollar? MCP, CLIs, RAG y agentes propios

Si eres un desarrollador típico —de los que ya han creado aplicaciones con backend, frontend y API— y no sabes qué estudiar a continuación, este artículo es para ti. Hoy te muestro cuatro temas actuales que puedes añadir a tu lista de estudio, y que cada vez más proyectos están pidiendo: MCPs, CLIs, RAG (con bases de datos vectoriales) y agentes de IA propios.

Una aclaración importante antes de empezar: nada de esto reemplaza a los sistemas tradicionales que hemos construido durante años (frontend + backend + base de datos). Son un añadido. Conocerlos vale la pena porque expande tu portafolio, te permite crear un SaaS que ofrezca este tipo de funcionalidades, o incluso detectar carencias en el ecosistema y desarrollar tus propias herramientas.

El contexto: el stack ya se estandarizó

En años anteriores dedicábamos mucho tiempo a comparar lenguajes, frameworks y resultados de encuestas como la de Stack Overflow o el State of JavaScript para decidir qué tecnología aprender. Esos recursos siguen existiendo (la encuesta de Stack Overflow 2025 ya tiene resultados y la del 2026 recién está activa), pero han dejado de ser el foco principal.

¿Por qué? Porque muchas herramientas de IA ya usan ese stack por debajo y prácticamente sabemos qué van a escoger:

• Frontend: React, casi siempre con Vite o Next.js
• Backend: algún framework sobre Node o Python
• Base de datos: PostgreSQL

Y esto no significa que la IA siempre te haga instalar Postgres localmente: muchas veces se apoya en un backend as a service como Supabase, InsForge o Convex. Al final son alternativas que por debajo usan el mismo ecosistema, solo que como soluciones ya hechas (más orientadas al vibe coding), mientras que escoger cada pieza una a una sigue siendo lo propio del desarrollo tradicional.

Con ese stack tan sencillo puedes crear prácticamente cualquier cosa: e-commerce, aplicaciones internas, sitios de noticias, blogs, etc. Y la razón de que hoy sea tan rápido es que brillan los agentes de IA para código: Claude Code (basado en los modelos Claude), Codex (basado en GPT) y OpenCode (que te da acceso a modelos abiertos). Editores como Cursor están al mismo nivel.

Esto es justamente lo que ha llevado a muchos a creer que "el desarrollo está hecho" y que ya no hace falta aprender nada más. Pero lo que ha ocurrido en los últimos años es lo contrario: alrededor de estos sistemas comunes han surgido otros más complejos que requieren conocer nuevos temas. Una API típica hoy la generas, documentas, testeas y despliegas en 10 o 20 minutos, base de datos incluida. La pregunta interesante viene después: "esos datos que acabas de crear… quisiera consultarlos desde Claude Code, desde Codex o desde ChatGPT". Y ahí es donde entran los cuatro temas de hoy.

1. MCP: la API de tu API

El Model Context Protocol (MCP) es un estándar que permite que las herramientas de IA entiendan y consulten tus sistemas. Mi forma favorita de describirlo: es como una API de una API, diseñada para que la IA la pueda entender.

Ya no es un experimento. Hoy prácticamente todos los agentes y aplicaciones de IA nuevas entienden este protocolo, igual que en su momento todo el mundo adoptó las APIs REST.

¿Para qué sirve en la práctica?

Imagina que tienes un e-commerce con productos, ventas y datos ya generados. Con un MCP, puedes preguntarle a Claude Desktop o a ChatGPT: "¿cuáles fueron mis ventas de los últimos meses?" o "dame estrategias basadas en mis datos", y la IA consultará tu sistema y te devolverá reportes o incluso gráficos.

El flujo es así: supón que tu API tiene una ruta como /api/sales. Si la llamas directamente, obtienes un JSON con un montón de datos. Pero el usuario puede preguntar algo mucho más natural: "¿qué días tuve más ventas este mes?". El MCP traduce esa pregunta a la llamada de API correspondiente, obtiene la respuesta y la formatea en lenguaje natural. Por eso es una "API de API": típicamente no va directo a la base de datos (podría, pero lo ideal es pasar por tu API), porque la mayoría de aplicaciones reales ya tienen una interfaz web o móvil consultando ese mismo backend. El MCP simplemente se convierte en otra forma más de consumir tu API.

¿Por qué aprenderlo ahora?

Muchas empresas se quedaron en "API + frontend". Pero las que están surgiendo sí ofrecen integración vía MCP, y a futuro los nuevos sistemas de facturación, ERPs, gestores de proyectos y CRMs van a ofrecer este tipo de integración. Se van a necesitar personas que sepan desarrollarlos.

Puedes crear MCPs en TypeScript, Kotlin, Java, Go y más. La sintaxis se parece mucho a crear una API, solo que conectada a un modelo inteligente. Eso sí: implica no solo saber desarrollar el servidor, sino también temas de diseño, porque hay varias formas de estructurar un MCP.

No solo para desarrolladores

Los agentes de consola (Claude Code, Codex, OpenCode) son muy "pro desarrollo". Pero también existen sus equivalentes para usuarios no técnicos: Claude Desktop, ChatGPT y muchos chats que soportan MCP. Piensa en un administrador de empresa que solo quiere preguntar y obtener sus reportes, sin importarle qué modelo o infraestructura hay por debajo. Ahí brilla el MCP.

En Claude Desktop, por ejemplo, los MCPs aparecen como conectores: yo tengo varios como Supabase, Excalidraw y otros. Puedes agregar un conector personalizado con la URL de tu MCP desplegado; algunos piden autenticación vía OAuth (client ID) y otros simplemente un token de autorización al momento de consultar datos.

2. CLIs: la alternativa (más simple) al MCP

Para los agentes que usan desarrolladores existe otra opción muy aparte del MCP: los CLIs, las herramientas de consola de toda la vida.

Un buen ejemplo es GitHub: existe el GitHub MCP Server (para conectar aplicaciones de escritorio a tus repositorios) y también el GitHub CLI. Ambos son proyectos oficiales y ambos llegan a lo mismo por caminos distintos: algunas aplicaciones solo permiten conectar un MCP, mientras que otras pueden aprovechar directamente un CLI instalado en tu sistema.

Por ejemplo, en Cursor puedes pedirle: "usando GitHub CLI, consulta mi último repositorio". Lo que hace el editor es ejecutar el comando de consola, leer la respuesta, descubrir qué otros comandos existen y llamarlos por sí mismo hasta darte la URL y toda la información del proyecto.

Es algo que el MCP también puede hacer, pero el CLI es mucho más fácil de crear. Incluso hay quien lo combina con skills: documentación que le ayuda a la IA a saber que existe ese CLI y cómo usarlo, mejorando las respuestas y ahorrando tokens porque el agente no tiene que averiguar qué comandos ejecutar.

Los CLIs existían mucho antes de la IA como otra forma de acceder a una API o a un sistema; lo nuevo es que ahora los agentes los aprovechan para conectarse a aplicaciones externas. El patrón se repite por todos lados: hay un Stripe MCP y también un Stripe CLI, y así con muchos proyectos populares.

3. RAG y bases de datos vectoriales: el chat dentro de tu propia app

MCPs y CLIs sirven para que aplicaciones externas se comuniquen con tu API. Pero ¿qué pasa con tu propio frontend? Es muy posible que te pidan crear un chat dentro de tu aplicación que consulte los datos de tu base de datos y responda ahí mismo, sin depender de Claude Desktop ni ChatGPT.

¿Por qué querría alguien esto? Principalmente por control: puedes saber quién consultó qué, y determinar quién tiene acceso a qué tipo de información. Todo queda integrado en una misma plataforma. Imagina un ERP que necesita su propio chat interno: para eso existe el tercer tipo de desarrollo, el RAG.

Cómo funciona (versión resumida)

En tu base de datos ya tienes tablas relacionadas: productos, usuarios, categorías, con sus llaves foráneas. El problema es que la IA no puede entender directamente esos datos "planos" (textos y números). Por ejemplo, un registro como nombre: Juan, apellido: Pérez, edad: 30, saldo: 3000 USD debe convertirse a un formato especial llamado embedding: básicamente, representar toda esa información como vectores numéricos.

Esos vectores se almacenan en una base de datos vectorial. Aquí tienes opciones:

• Bases vectoriales dedicadas: Pinecone y Chroma (competidores directos)
• Plugins para tu base de datos existente: tanto en SQL como en NoSQL. En PostgreSQL, por ejemplo, está pgvector, que te permite crear columnas especiales que almacenan vectores dentro de tus tablas, o una tabla aparte solo para datos vectoriales.

Para convertir tus datos a embeddings necesitas un modelo de embeddings especializado; OpenAI tiene el suyo, Anthropic también, y hay muchos más.

El punto clave: modelado de datos

Aunque la IA puede generar gran parte de esto por ti, aquí sí necesitas entender modelado de datos. Si tu aplicación es pequeña, puedes guardar todo en una tabla o unas cuantas columnas y listo. Pero si es un negocio de verdad —un ERP con usuarios reales a los que ofreces un RAG— necesitas entender cómo extender tu base de datos con este nuevo formato (o apoyarte en una adicional) para que el sistema escale cuando crezca.

4. Crear tu propio agente de IA

El último tema: construir tu propio agente. Los agentes de consola ya vienen hechos para escribir código, pero no son los únicos: hay listas enormes de agentes de terminal alternativos, y en el fondo todos hacen casi lo mismo — conectan un modelo de IA existente y le dan herramientas para responder o ejecutar comandos.

Lo interesante es que también existen frameworks para crear agentes desde cero, como eve, un proyecto relativamente nuevo de Vercel. La propia empresa lo describe como "Next.js, pero para agentes": las instrucciones y skills se escriben en Markdown, las herramientas en TypeScript, y al ejecutar el proyecto ya tienes un agente personalizado, listo para conectarse a canales como Slack, Discord o la web. Internamente Vercel comenta que lo usan bastante para automatizaciones.

Siendo honesto, este sería el último tema que te sugeriría aprender de los cuatro: todavía no he visto tanto uso real. Pero seguramente habrá empresas que en algún momento necesiten personalizar las respuestas de un agente o cambiar internamente qué herramientas utiliza, así que es una opción adicional a tener en el radar.

Conclusión

Recapitulando, hoy hemos hablado de:

1. MCPs — la "API de tu API" para que herramientas de IA consulten tus sistemas
2. CLIs — la alternativa más simple que los agentes aprovechan cada vez más
3. RAG + bases de datos vectoriales — el chat con tus propios datos, dentro de tu propia app
4. Agentes propios — frameworks como eve para construir tu agente personalizado

Todo esto te permite crear aplicaciones modernas encima de aplicaciones existentes. No es un reemplazo: de hecho, para que todo esto funcione, por lo general necesitas una API, y esa la tienes que desarrollar como siempre (con o sin ayuda de un agente).

Este contenido no está pensado para vibe coding ni para quienes recién empiezan, sino para desarrolladores que ya dominan frameworks y lenguajes y quieren saltar a algo más que el sistema común de API + frontend + base de datos. Son proyectos retadores si nunca has trabajado con ellos, pero creo que te van a resultar divertidos: al final estás uniendo la API de un modelo inteligente a tus herramientas y ofreciéndolo como una nueva forma de solución — otro tipo de aplicación cliente para tus APIs.

Si tienes alguna duda o idea, déjala en los comentarios. Y si quieres profundizar en RAG, te dejo el video donde muestro cómo crear uno paso a paso.