De Software Engineer a AI Engineer: el roadmap más realista

Si eres desarrollador de software y has escuchado el término AI Engineer, probablemente pienses que es un rol complicado, una carrera nueva que habría que empezar desde cero. La realidad es otra: el AI Engineering es una continuación natural del desarrollo de software, y cualquiera que ya sepa crear aplicaciones puede aprenderlo.

En este artículo te doy un paso a paso de qué temas aprender y qué conceptos deberías dominar si quieres actualizarte y poner en tu CV que ahora eres AI Engineer, y no solamente Software Engineer.

Nota: este roadmap no es para personas que recién empiezan a programar. Está pensado para quienes ya llevan un tiempo desarrollando —escribir código, leer código, crear software en general— y quieren migrar o continuar su aprendizaje hacia el área de IA.

Las bases que ya deberías tener

Casi todas las aplicaciones se componen de tres partes que cualquier desarrollador conoce de alguna forma:

Bases de datos. SQL, NoSQL e incluso bases de datos nuevas que van surgiendo. Mi sugerencia: cualquier SQL sirve, pero si tienes que elegir, aprende PostgreSQL o algo similar.

APIs y backend. Lenguajes como Go, Python, JavaScript/TypeScript con Node, Java, .NET y sus respectivos frameworks, que facilitan mucho el trabajo.

Frontend. Poder crear interfaces o alguna UI que consuma la API.

A esto se suman herramientas transversales que todo desarrollador usa sin importar su stack:

• Git, para el control de versiones.
• Conceptos básicos de redes, de forma práctica: HTTP, UDP, FTP... cómo se comunican los sistemas entre sí.
• Docker, para empaquetar aplicaciones en contenedores y mantenerlas aisladas. Además está muy relacionado con la nube.

Si ya creas aplicaciones con esto, lo único que te falta es la parte de IA. Pero antes, hay un tema previo que te recomiendo no saltarte.

System Design: el paso previo que casi nadie hace

Antes de entrar de lleno en IA, te recomiendo aprender System Design: diseñar sistemas completos sin pensar todavía en lenguajes o frameworks, sino en los servicios, cómo se despliegan las aplicaciones y cómo se conectan entre sí. Es como el mapa de toda tu aplicación.

Si buscas en internet vas a encontrar explicaciones de cómo funcionan sistemas como los de Instagram, Facebook o YouTube. Podrías pensar que son solo un backend y un frontend, pero detrás hay sistemas bastante complejos, algunos incluso con componentes internos propietarios.

Dos repositorios excelentes (y gratuitos) para estudiar esto:

• System Design — explica protocolos de internet, servicios de almacenamiento, comunicación entre múltiples servicios (proxies, colas, publish/subscribe), diseño de bases de datos y principios como ACID y CAP.
• System Design Primer — conceptos generales de APIs, comunicación con servicios en la nube y diseño de sistemas escalables.

¿Por qué importa esto para IA? Porque cuando veas cualquier desarrollo con IA, el diseño va a ser exactamente igual: una API, una base de datos, una aplicación web... solo que van a aparecer uno o varios recuadros nuevos en tu diagrama: los componentes de IA. Si dominas System Design, integrar IA es simplemente extender un mapa que ya sabes leer.

No confundas los roles: AI Engineer vs ML Engineer vs AI Researcher

Antes de seguir, dejemos claro de qué rol estamos hablando, porque hay tres niveles muy distintos:

AI Engineer. Crea aplicaciones de toda la vida, pero utilizando modelos de IA. Es trabajo práctico: integrar modelos en sistemas reales. Un desarrollador de software está mucho más cerca de este rol de lo que cree.

Machine Learning Engineer. Un rol más especializado: entrena modelos, hace fine-tuning, puede implementar optimizaciones de papers recientes. Aquí también entran áreas como MLOps (desplegar y operar modelos en producción), donde muchos perfiles DevOps están migrando.

AI Researcher. El nivel más avanzado. Ya no lee investigaciones: las crea. Diseña modelos desde su estructura teórica. Requiere matemática avanzada, normalmente un PhD, y muchas veces financiación de laboratorios de IA.

Este roadmap se enfoca en el primero, que es mucho más accesible de lo que parece.

Paso 1: entender las bases de los modelos de IA

Todo el mundo puede usar un modelo de IA, pero para integrarlos en sistemas necesitas conocer algunos conceptos clave:

• Tokens: la unidad en la que los modelos procesan y generan las respuestas (y en la que te cobran, como veremos).
• Contexto: cuánta información puede manejar el modelo en una conversación antes de que empiece a "inventar cosas".
• Temperatura: el parámetro que controla qué tan creativo o determinista es el modelo. Temperatura cero es básicamente decirle "no te inventes nada; si no sabes, responde que no sabes".
• Roles en una conversación: system (las instrucciones que vienen incluidas en el chat), user (los mensajes del usuario) y assistant (lo que responde el modelo).

Son términos que se aprenden leyendo un poco, pero son la base de todo lo que viene después.

Paso 2: las APIs de IA (y el tema del que nadie te habla: los costos)

Aquí es donde empiezas a usar modelos dentro de tus propias aplicaciones: un chat que consulta tu base de datos, un backend que procesa cada mensaje entrante con IA, etc.

Hay dos proveedores que todo el mundo termina usando en algún punto:

• Anthropic, con los modelos Claude en sus distintas versiones.
• OpenAI, con GPT en sus múltiples variantes, incluyendo generación de imágenes (algo que Anthropic no ofrece).

Suscripción ≠ API: el error que cometen muchos clientes

Esto es muy importante y lo he visto con clientes reales: creen que pagando $100 o $200 ya tienen "IA ilimitada" para su proyecto. No funciona así.

• La suscripción (Claude Code, Codex con ChatGPT, etc.) es para que tú desarrolles. Las empresas subsidian ese uso: una suscripción de $200 no cubre el costo real de cómputo que consumes.
• La API se paga por uso, generalmente por millón de tokens, y es lo que necesitas para que tu aplicación funcione en producción.

Tarde o temprano vas a usar APIs y vas a pagar por uso. Manejar bien los precios te permite decirle a tu cliente: "¿cuánto estás dispuesto a pagar por esta característica inteligente?" — y decidir si vale la pena implementarla. Este último año muchas empresas han descubierto en carne propia lo caro que es tener modelos funcionando constantemente.

¿Y los modelos chinos?

Son una alternativa real porque sus APIs suelen ser mucho más baratas. Pero seamos honestos: no son exactamente iguales. Para un chat básico que entienda cosas simples, pueden ofrecerte el mismo nivel de calidad. Para tareas complejas —interpretar una imagen con pocos detalles, procesar archivos muy grandes donde necesitas máxima precisión— Anthropic y OpenAI siguen respondiendo mejor.

Lo técnico de trabajar con APIs de IA

Una vez elijas tu proveedor, vas a aprender cosas que ya conoces de cualquier API:

• Cómo enviar mensajes y recibir respuestas (que suelen venir en Markdown, aunque puedes pedirlas en JSON, HTML, etc.).
• Manejo de múltiples usuarios y conversaciones concurrentes.
• Manejo de errores y tolerancia a fallos, porque estas APIs no siempre responden bien.

Si ya has desarrollado APIs normales, todo esto te va a sonar familiar.

Paso 3: más allá del chat

El error típico del que recién empieza es pensar que todo con IA es un chat. No necesitas que un usuario converse directamente con el modelo. Algunos ejemplos:

• UI con features inteligentes: un botón que al hacer clic rellena un campo de texto generado por IA.
• Procesamiento en el backend: llega un correo a tu sistema → antes de guardarlo en la base de datos, una llamada a la API lo resume, lo valida o lo clasifica para decidir si vale la pena procesarlo.
• Auto-reparación de despliegues: si un deploy falla, el error se pasa a una API de IA, esta corrige el código, hace push a GitHub y el despliegue se vuelve a disparar. Si falla de nuevo, repite el ciclo. (Ojo: aquí el costo por uso importa muchísimo.)

Paso 4: Prompt Engineering (sin el humo)

El prompt engineering tiene mala reputación porque cuando salió se sobreexplotó la idea de que era una habilidad imprescindible. La realidad actual: los modelos ya interpretan muy bien el contexto y no necesitan tantas instrucciones. De hecho, hace poco el equipo de Claude Code eliminó una enorme cantidad de prompts internos de la herramienta porque los modelos actuales ya no los necesitan.

¿Entonces no sirve? Sí sirve, pero en su justa medida: cuando desarrollas aplicaciones propias, tu sistema tiene que saber cómo comportarse. Es tan simple como definir un texto de sistema:

• En un manejador de despliegues: "Eres un sistema de manejo de errores de despliegue."
• En un backend de correos: "Eres un clasificador de correos."

Paso 5: Function Calling (más importante que el prompt engineering)

Esto sí es clave: el function calling (algunas herramientas lo llaman tools) es la capacidad de que la IA ejecute código para hacer algo, no solo para responder texto.

Siguiendo el ejemplo del clasificador de correos: si la IA decide que un correo debe eliminarse o moverse, ¿cómo lo hace? Con una función de toda la vida —un script en Python o el lenguaje que uses— que el modelo puede llamar y ejecutar por ti. El modelo deja de sugerir acciones y pasa a ejecutarlas.

Paso 6: las aplicaciones prácticas — RAG, MCP, CLIs y Skills

Con todo lo anterior ya puedes construir los tipos de aplicación que realmente se venden hoy:

RAG y bases de datos vectoriales

RAG (Retrieval-Augmented Generation) es la forma en que las empresas conectan una IA con sus datos: ventas, recursos humanos, pagos, inventario... para que el modelo pueda leerlos y generar reportes, predicciones o automatizar tareas de varios pasos.

Aquí entra la base de datos vectorial. Una IA no puede "entender" directamente tu base de datos SQL: necesitas convertir tus datos a un formato especial llamado vector. Cuando decimos que la IA "entiende tus datos", en realidad está consultando esa versión vectorizada. Existen bases de datos especializadas como Pinecone o Chroma, aunque también puedes guardar vectores en tu base de datos existente.

Si te preguntas por dónde empezar: empieza con RAG. Es la forma más básica de entender cómo una IA responde a partir de tus datos, y es muy fácil de implementar.

MCP

El MCP funciona como una API adicional, un conector para chats ya existentes. Si tus usuarios usan ChatGPT o Claude Desktop, esas interfaces permiten conectar un MCP. El usuario pregunta "¿cuáles son mis ventas de este año?", y el MCP traduce eso en una llamada a tu API (algo como /ventas?desde=2026).

Lo interesante del modelo de negocio: la suscripción la paga el usuario (ya está suscrito a esas plataformas), así que tú no pagas API externa; solo despliegas tu "traductor" MCP.

Ojo con la seguridad: diseñar un MCP es diseñar una API al final del día. Tienes que documentar bien qué funciones puede llamar, porque estos chats podrían acceder a datos que no deberían.

CLIs y Skills

Otra forma más avanzada: crear un CLI que funcione como cliente de tu API, de manera que una IA pueda usarlo como herramienta de consola para consultar o manipular tu sistema. Esto se combina con los skills, que son básicamente prompts reutilizables definidos de forma resumida — se aprenden en minutos.

Igual que con MCP: define bien qué puede hacer la IA con tu CLI, porque si no, podría llegar a reescribir código que no debería tocar.

Herramientas del ecosistema

A medida que avances vas a encontrar frameworks como LangChain, LlamaIndex, Temporal o Inngest, que ayudan a vectorizar datos o procesar información con modelos ya desplegados. No hace falta aprenderlos todos: implementar cada uno depende del proyecto, pero te los vas a cruzar tarde o temprano. Incluso ya se habla de generar grafos de conocimiento a partir de tu información — conceptos nuevos van a seguir surgiendo.

Paso 7: LLMOps — llevar modelos a producción

Tarde o temprano una empresa te va a pedir no depender de una API externa, generalmente por privacidad: no quieren que sus datos salgan de su sistema. Ahí entra el LLMOps: llevar a producción modelos o aplicaciones que los usan.

Dos escenarios:

1. Modelo en tu propia nube: igual que despliegas una app en AWS, Google Cloud o Azure, puedes desplegar un modelo open source (por ejemplo un GPT de pesos abiertos) y pagar por el uso de tu nube, con la garantía de que todo se procesa dentro de tu infraestructura.
2. Hardware propio: IA en local, que es todo un tema por sí mismo.

Y con esto vienen conceptos de producción:

• Rate limiting, para que no saturen el modelo con consultas simultáneas.
• Optimización de costos por consulta.
• Model routing: enrutar de un modelo a otro según el tipo de entrada (audio, imagen) o según qué modelo responde mejor a cada tarea.
• Caching: guardar respuestas ya generadas para no regenerar lo mismo.
• Escalado: cuántos usuarios o consultas concurrentes puede soportar tu sistema.

Resumen: el roadmap completo

1. Bases de desarrollo (ya las tienes): lenguaje, base de datos, APIs, frontend, Git, redes, Docker.
2. System Design: estudia system-design y system-design-primer. La IA solo agrega recuadros nuevos a diagramas que ya sabes diseñar.
3. Fundamentos de modelos: tokens, contexto, temperatura, roles.
4. APIs de IA: Anthropic, OpenAI, alternativas más baratas, y sobre todo entender el modelo de costos (API por uso ≠ suscripción).
5. Prompt engineering y function calling: instrucciones de sistema y darle herramientas ejecutables al modelo.
6. Implementaciones prácticas: RAG (empieza aquí), MCP, CLIs, skills.
7. LLMOps: despliegue, rate limiting, routing, caching, escalado.

Fíjate que en ningún momento hablamos de matemáticas, modelos de inferencia ni teoría pura. Todo tiene un uso práctico: la idea es generar aplicaciones que utilicen los modelos que ya funcionan hoy. Si después te interesa entrenar tus primeros modelos o hacer fine-tuning, ahí ya entras en terreno de machine learning — pero eso es otro roadmap.

No estás empezando una carrera nueva desde cero. Es una continuación. Una actualización de estos días.