La ingeniería de IA es uno de los trabajos mejor pagados y de más rápido crecimiento en tecnología hoy en día. Y la puerta de entrada nunca ha estado más abierta.
La mayoría de las guías se equivocan. Te dan un muro de teoría, te dicen que domines álgebra lineal y matemáticas de redes neuronales, y te pierden para la segunda semana.
O te entierran en 80 enlaces sin orden ni conclusión, para que pases más tiempo decidiendo qué estudiar que estudiando realmente.
Leí las hojas de ruta populares, probé las herramientas que recomiendan y construí la versión que le daría a un amigo que está cambiando de carrera y tiene trabajo real que hacer.
Sin título en matemáticas. Sin plan de cuatro años.
Cuatro meses enfocados, una opción clara por habilidad, indicaciones reales que puedes copiar, y los errores que silenciosamente matan la mayoría de los cambios de carrera antes de que empiecen.
Aquí te explico por qué creo que el momento importa, y luego la ruta completa.
Por qué la puerta está abierta (y puedo demostrarlo)
Probablemente te han dicho que la IA va a quitar empleos.
Aquí está la parte que recibe menos atención: está creando una categoría específica y bien remunerada de trabajo más rápido que casi cualquier otra cosa en el mercado, y el guardián habitual está desapareciendo.
El Barómetro Global de Empleos en IA 2026 de PwC analizó más de mil millones de ofertas de trabajo en seis continentes. Tres hallazgos importan para cualquiera que esté considerando un cambio.
Primero, los trabajos que requieren habilidades de IA están creciendo aproximadamente ocho veces más rápido que el mercado general. Los roles con habilidades de IA crecieron un 69% mientras que el mercado laboral total creció un 9%.
Eso no es un error de redondeo. Es una categoría que se está distanciando de todo lo que la rodea.
Segundo, la prima salarial es real y está aumentando. Los trabajadores con habilidades de IA obtienen una prima salarial del 62% sobre roles comparables sin ellas, frente al 57% del año anterior.
Las empresas están pagando más, no menos, por personas que realmente puedan construir con estas herramientas.
Tercero, y esto es lo que cambia las reglas del juego para quienes cambian de carrera: el requisito de título universitario está disminuyendo, y está disminuyendo más rápido precisamente para estos roles.
PwC encontró que la proporción de trabajos aumentados por IA que requieren un título cayó del 66% al 59% entre 2019 y 2024.
Para los trabajos donde la IA automatiza partes del trabajo, cayó aún más, del 53% al 44%. Los empleadores están eliminando el filtro de credenciales más rápido en trabajos expuestos a la IA que en cualquier otro lugar.
Hay un número más que vale la pena considerar. En EE. UU., los roles de nivel inicial más expuestos a la IA crecieron un 35% desde 2019.
En el mismo período, otros roles de nivel inicial disminuyeron un 10%. El escalón más bajo de la escalera de la IA se está ensanchando mientras que el resto del mercado de nivel inicial se reduce.
Ahora el contrapeso honesto, porque no estoy aquí para venderte una fantasía.
PwC también encontró que los roles de nivel inicial expuestos a la IA piden cada vez más habilidades que solían reservarse para personas senior: criterio, comunicación, la capacidad de asumir la responsabilidad de un resultado en lugar de una tarea.
El listón no es más bajo en todos los ámbitos. Se ha movido. Es menos "¿tienes el título?" y más "¿puedes realmente hacer que esto funcione y explicar por qué funciona?"
Léelo como una mala noticia si eres un recién graduado sin experiencia laboral. Léelo como una buena noticia si vienes de otra carrera, porque ya tienes lo que ahora están pidiendo.
Has entregado proyectos. Has tratado con partes interesadas. Has asumido la responsabilidad de resultados bajo presión.
Un joven de 22 años con un título en Ciencias de la Computación generalmente no lo ha hecho. Si combinas tu criterio existente con las habilidades técnicas de esta guía, no estás detrás de los nuevos graduados.
En el eje que más importa a los empleadores, estás por delante de ellos.
Esa es la ventaja del que cambia de carrera, y casi ninguna hoja de ruta te lo cuenta. Guárdalo en el bolsillo durante los cuatro meses. Es la razón por la que esto es realista para ti específicamente.
Una palabra rápida sobre el dinero, porque querrás los números reales antes de comprometerte cuatro meses.
Daré el desglose completo al final con las fuentes, pero la versión corta: a mediados de 2026, Glassdoor sitúa el salario promedio del ingeniero de IA en EE. UU. en alrededor de $143,500, con un rango típico de aproximadamente $115,000 a $181,000.
Los roles senior son mucho más altos. Los reclutadores que colocan personas en trabajos de IA en producción reportan salarios base de nivel medio que se agrupan entre $155,000 y $200,000.
Estas no son cifras infladas sacadas de un hilo de hype. Son actuales, y te mostraré de dónde viene cada una.
Qué hace realmente un ingeniero de IA (la versión de 60 segundos)
Antes del plan, eliminemos la mayor fuente de intimidación, porque detiene a más personas que cualquier obstáculo técnico.
Cuando la mayoría de la gente escucha "ingeniero de IA", se imagina a alguien en un laboratorio entrenando un modelo gigante desde cero, rodeado de GPUs y matemáticas que nunca entenderán.
Ese es un trabajo diferente. Se llama científico investigador o investigador de ML, hay relativamente pocos, y generalmente sí requiere títulos avanzados.
El trabajo de ingeniero de IA que está creciendo ocho veces más rápido que el mercado es algo completamente diferente.
Construyes productos y funciones sobre modelos que ya existen. Tomas Claude, o GPT, o un modelo de código abierto, y haces que haga un trabajo específico y confiable dentro de una aplicación real.
En la práctica, eso significa que te conectas a las API de los modelos, diseñas las indicaciones y el contexto que les das, obtienes datos estructurados, conectas el modelo a herramientas y bases de datos, haces que recupere la información correcta, manejas todo lo que puede salir mal y lo despliegas para que la gente real pueda usarlo.
Se sitúa entre la ingeniería de software, el trabajo de producto y la IA aplicada. Eres un constructor, no un investigador.
Aquí está la prueba de una línea que usaría. Si puedes hacer que un LLM realice un trabajo específico de manera confiable dentro de una aplicación, y entiendes lo suficiente para arreglarlo cuando se rompe, eres un ingeniero de IA. Eso es todo.
Todo en esta guía está dirigido a lograr que esa frase sea cierta para ti.
No necesitas saber cómo funciona un transformer internamente. No necesitas cálculo. No necesitas poder derivar la retropropagación.
Necesitas ser un constructor competente que entienda cómo trabajar con estos modelos en el mundo real.
Esa es una habilidad que se puede aprender, y cuatro meses enfocados son suficientes para volverse funcional en ella.
Lee esto antes del Mes 1: los 4 errores que matan los cambios de carrera
Pongo esto antes de la hoja de ruta a propósito.
La mayoría de las guías entierran los errores al final, pero los errores que terminan un cambio de carrera ocurren en la segunda semana, no en el tercer mes. Si solo recuerdas una sección de esta guía, que sea esta.
He visto a personas, incluyendo una versión anterior de mí mismo, cometer cada uno de estos. Ninguno tiene que ver con la inteligencia.
Tienen que ver con la estrategia. Arregla la estrategia y los cuatro meses realmente funcionan.
Error 1: Empezar con teoría y matemáticas.
Te emocionas, quieres hacerlo bien, así que buscas un curso de machine learning y empiezas con álgebra lineal, descenso de gradiente y las matemáticas detrás de las redes neuronales.
Tres semanas después, has visto muchas conferencias, no puedes construir nada y te sientes un impostor. Así que te rindes.
La solución: sáltatelo. Para el trabajo al que apuntas, no necesitas derivar las matemáticas.
Necesitas construir.
Aprenderás los conceptos que realmente necesitas a medida que los encuentres en proyectos reales, y se quedarán porque estarán vinculados a algo que construiste.
La teoría primero es la razón más común por la que las personas inteligentes abandonan esto. No empieces ahí.
Error 2: Ver tutoriales en lugar de construir.
Este es engañoso porque se siente como progreso. Ves un curso de Python de cuatro horas, asientes con la cabeza, sientes que aprendiste algo. No lo hiciste.
Viste a otra persona aprender algo. En el momento en que abres un archivo en blanco, nada de eso está ahí.
La solución: la regla de los 30 minutos. Por cada hora que pases viendo o leyendo, pasa al menos 30 minutos construyendo algo sin tener un tutorial abierto.
Escribe los ejemplos tú mismo. Rómpelos. Cámbialos. Obtén errores y arréglalos. Los errores son el aprendizaje.
Una persona que construye mal durante cuatro meses le gana a una persona que mira perfectamente durante cuatro meses, siempre.
Los empleadores pueden ver la diferencia en diez segundos mirando tu GitHub.
Error 3: Aprender herramientas en lugar de habilidades.
Escuchas que LangChain es lo que se usa, así que te profundizas en LangChain.
Seis meses después, el campo ha cambiado, todos están usando otra cosa, y tu conocimiento de LangChain se siente desperdiciado. Así que persigues la nueva herramienta.
Luego esa también cambia. Siempre estás detrás porque estás optimizando para la capa incorrecta.
La solución: aprende la habilidad debajo de la herramienta. La habilidad de escribir una indicación que produzca resultados confiables no caduca cuando un framework se actualiza.
La habilidad de obtener datos estructurados de un modelo, o evaluar si tu sistema realmente funciona, o decidir cuándo una tarea necesita un agente versus una sola llamada, esas se transfieren a través de cada herramienta que existirá.
Aprende herramientas como una forma de practicar habilidades, no como el objetivo. Esta guía está organizada en torno a habilidades precisamente por esta razón.
Error 4: Esperar hasta sentirte listo para construir en público.
Decides que empezarás a compartir tu trabajo, postularte a roles u ofrecer servicios freelance una vez que estés "listo".
Nunca te sentirás listo. Listo es un sentimiento que llega después de que empiezas, no antes.
Mientras tanto, las personas que están siendo contratadas y consiguiendo clientes son las que empezaron a compartir trabajo preliminar meses antes de sentirse calificados.
La solución: empieza a construir en público desde el Mes 1. Publica la pequeña cosa que hiciste. Escribe sobre lo que aprendiste.
Pon cada proyecto en GitHub el día que lo termines, incluso los feos.
La brecha entre "estoy aprendiendo" y "estoy construyendo visiblemente" es donde la mayoría de los que cambian de carrera se quedan atascados durante un año. Ciérrala temprano.
Nadie está mirando lo suficientemente de cerca como para que tu trabajo temprano te avergüence, y la capitalización comienza el día que empiezas.
Mantén estos cuatro a la vista durante todo el camino.
La hoja de ruta a continuación está diseñada para evitarlos todos por defecto: primero la habilidad, primero la construcción, independiente de la herramienta, público desde el día uno.
Mes 1: Python y la fontanería
Tu objetivo este mes: convertirte en un desarrollador de Python funcional que pueda llamar a una API, gestionar un proyecto pequeño y dejar de buscar sintaxis básica en Google.
No un experto. Funcional.
Todo en los Meses 2 a 4 asume que puedes escribir Python limpio y trabajar en una terminal. Esta es la base, y apresurarla te perjudicará más adelante.
Esto es lo que debes internalizar antes de empezar: la ingeniería de IA es ingeniería de software primero. La parte de IA se asienta sobre una pila de software normal.
Si la pila subyacente es inestable, la parte de IA nunca será confiable. Así que el Mes 1 se trata de familiarizarte lo suficiente con los conceptos básicos para que dejen de ser un obstáculo.
Te daré una opción principal por habilidad, con un veredicto claro sobre por qué. Deliberadamente no te doy cinco opciones por tema. La elección es enemiga del impulso.
Elige la que te señalo, y solo desvíate si realmente no funciona para ti.
Python
Python es el lenguaje de todo este campo. Casi todas las bibliotecas, API, tutoriales y trabajos que tocarás en los próximos cuatro meses están en Python. Lo aprendes, y todo lo demás se vuelve más fácil.
Mi elección: CS50P, Introducción a la Programación con Python de Harvard. Gratuito, riguroso y te obliga a resolver problemas en lugar de ver a alguien más resolverlos.
Los conjuntos de problemas son todo el valor. Es más exigente que un curso suave de YouTube, y ese es el punto.
Quieres la versión que te haga esforzarte un poco, porque el esfuerzo es donde se forma la habilidad.
Encuéntralo en cs50.harvard.edu/python.
Si CS50P se siente demasiado empinado como principiante absoluto, el curso de Python de freeCodeCamp en YouTube es una rampa de entrada más suave, pero trátalo como un calentamiento, no como el evento principal.
Vuelve a CS50P una vez que no le temas a un archivo en blanco.
En qué enfocarte realmente, en orden aproximado: variables y tipos de datos, bucles y condicionales, funciones, luego los tipos de colección (listas, diccionarios, conjuntos, tuplas).
Luego manejo de archivos y lectura/escritura de JSON, que usarás constantemente con las API de IA.
Luego lo suficiente de clases y conceptos básicos de orientación a objetos para leer el código de otros sin pánico.
Luego manejo de errores con try y except.
Finalmente, entornos virtuales y pip, para que puedas instalar paquetes sin romper tu sistema.
No intentes memorizar nada de esto. Entiéndelo lo suficientemente bien como para buscarlo rápido, y construye con él hasta que se quede.
Tu objetivo de construcción del Mes 1 para Python: una pequeña herramienta de línea de comandos que haga algo real.
Un rastreador de gastos que lea y escriba en un archivo JSON es una buena opción. O un script que llame a una API pública gratuita e imprima los resultados en un formato limpio.
Algo con quizás 60 a 100 líneas de tu propio código.
No importa si es feo. Importa que lo escribiste.
Aprendiendo con IA desde el día uno
Aquí es donde haría algo que las viejas hojas de ruta no hacen: usar IA para aprender IA, comenzando en la primera semana.
Tienes acceso al mejor tutor paciente jamás construido, y no cuesta nada en los niveles gratuitos. Cuando te encuentres con un error que no entiendes, no pases 40 minutos en un foro.
Pégalo en Claude o ChatGPT y pídele que te explique el error en lenguaje sencillo y te guíe hacia la solución sin darte la respuesta directamente.
Aquí tienes una indicación para copiar y pegar que configuraría el primer día. Guárdala.
Este es el primero de varios artefactos en esta guía que vale la pena marcar.
Indicación: Tu compañero de aprendizaje de Python
(Marco: Compañero de Aprendizaje FAG, por AI Guides)
1Tu trabajo: actuar como mi paciente tutor de Python mientras aprendo a programar como alguien que cambia de carrera.23Contexto sobre mí:4- Estoy aprendiendo Python para convertirme en ingeniero de IA.5- Soy un principiante total en programación, pero no en trabajar duro.6- Aprendo mejor haciendo, no recibiendo respuestas hechas.78Qué hacer:9- Cuando pegue un error, explícame en lenguaje sencillo qué significa y qué10 lo está causando probablemente. No me des solo el código corregido.11- Señálame hacia la solución con una pista primero. Solo muestra la solución completa12 si te lo pido dos veces.13- Cuando comparta código que escribí, dime una cosa que funciona y una cosa14 que podría mejorar. Limítate a esas dos.15- Después de que algo funcione, hazme una pregunta corta para comprobar16 si realmente lo entendí.1718Reglas:19- Sin jerga sin una definición en lenguaje sencillo de una línea al lado.20- Asume que quiero aprender, no solo aprobar. Un poco más lento está bien.21- Si estoy a punto de adquirir un mal hábito, dímelo directamente y con amabilidad.2223Salida: conversacional, corta, un concepto a la vez.
Usa eso todos los días este mes. Convierte las partes frustrantes de aprender a programar en una conversación en lugar de un muro.
También te vuelve fluido en la creación de indicaciones, que es la habilidad central del Mes 2, antes de que siquiera sepas que eso está sucediendo.
Una advertencia para que no desarrolles el hábito incorrecto: usa la IA para entender y desbloquear, no para que escriba todo por ti.
Si dejas que escriba tu código mientras miras, vuelves al Error 2.
Haz que explique. Tú escribes.
Git y GitHub
Git es la forma en que los desarrolladores guardan, versionan y comparten código.
GitHub es donde tu trabajo vive en público y se convierte en un portafolio.
Usarás ambos constantemente, y para alguien que cambia de carrera, GitHub es lo más parecido a un currículum que tienes hasta que tengas uno.
Mi elección: GitHub Skills. Gratuito, interactivo y construido por GitHub dentro del propio GitHub, para que aprendas la herramienta usándola. Empieza ahí en lugar de leer sobre Git en abstracto.
Encuéntralo en skills.github.com.
Si el modelo de ramificación y fusión te confunde, y confunde a todos al principio, la herramienta visual Learn Git Branching lo aclara al permitirte ver cómo se mueven las ramas.
En qué enfocarte: el bucle central de init, add, commit, push y pull. Luego ramificación y fusión.
Luego qué hace un archivo .gitignore y por qué nunca debes confirmar secretos o claves de API en un repositorio público, lo cual importa enormemente una vez que trabajes con API de pago.
Luego cómo escribir un README básico, porque tus README harán un trabajo real en tu búsqueda de empleo más adelante.
El hábito a construir este mes: cada proyecto que toques, incluso un script de 20 líneas, va a un repositorio de GitHub el día que lo hagas.
Esta es la solución del Error 4 en la práctica. Estás construyendo en público, en silencio, desde el principio.
Para el Mes 4, tendrás un rastro de trabajo en lugar de un perfil en blanco.
La terminal
Ejecutarás scripts, instalarás paquetes y gestionarás proyectos desde la línea de comandos constantemente.
Ser lento o tener miedo en la terminal es un lastre real para todo lo demás, y es algo fácil de arreglar.
Mi elección: un curso corto para principiantes sobre la terminal para cubrir lo básico, luego solo vive en ella. Los materiales del "Semestre Perdido" del MIT son más profundos si los quieres, pero para el Mes 1 solo necesitas navegación y ejecución.
Aprende cd, ls, pwd, mkdir y rm para moverte y gestionar archivos.
Aprende cat y grep para leer y buscar.
Aprende cómo ejecutar un script de Python desde la terminal y cómo establecer una variable de entorno, que necesitarás en el momento en que manejes claves de API.
No necesitas convertirte en un mago de la terminal. Necesitas dejar de dudar.
Una semana usando la terminal para todo, incluso cosas que normalmente harías con el ratón, te lleva allí.
API, JSON y HTTP
Este es el puente hacia el Mes 2.
Desde el primer día de construcción con LLMs, estarás haciendo llamadas a API, lo que significa que necesitas entender cómo funcionan las API web antes de tocar las herramientas de OpenAI o Anthropic.
Mi elección: la descripción general de HTTP de MDN Web Docs para los conceptos, más la documentación de la biblioteca requests de Python para hacerlo en código.
MDN explica cómo funcionan las solicitudes y respuestas más claramente que cualquier otra cosa gratuita.
Luego requests te muestra cómo hacer esas llamadas en Python en unas pocas líneas.
En qué enfocarte: qué son las solicitudes GET y POST y cómo hacerlas en Python.
Leer y escribir JSON, que es el formato que habla toda API de IA.
Los códigos de estado HTTP y qué significan los comunes, especialmente 200 para éxito, 401 para una clave de API incorrecta, 429 para límite de velocidad y 500 para un error del servidor, porque verás todos estos constantemente.
Qué es una clave de API y cómo funciona la autenticación básica.
Y una introducción ligera a lo que hacen async y await en Python, que necesitarás cuando empieces a transmitir respuestas de modelos más adelante.
No te profundices en async ahora.
Solo sabe que existe y aproximadamente qué problema resuelve.
Tu objetivo de construcción aquí: un script de Python que llame a una API pública gratuita, una que no necesite clave como la API meteorológica Open-Meteo, e imprima el resultado como una salida formateada limpia.
Esta es una versión pequeña de exactamente lo que harás durante todo el Mes 2, solo que sin la parte de IA todavía.
Una nota rápida sobre SQL
No necesitas ser un experto en datos, pero necesitarás regularmente mirar y consultar datos, y el SQL básico te salva constantemente.
Mi elección es SQLBolt, que es gratuito, interactivo y te enseña el núcleo de SQL en aproximadamente 20 lecciones cortas en el navegador.
Encuéntralo en sqlbolt.com.
Enfócate en SELECT, WHERE, GROUP BY, JOIN y ORDER BY.
Eso es suficiente por ahora.
Puedes profundizar en el momento en que un proyecto lo exija.
Hito del Mes 1
Al final del mes, deberías poder escribir un programa en Python que lea y escriba archivos, llame a una API y maneje sus propios errores sin fallar.
Deberías versionar ese código con Git y tenerlo vivo en un repositorio de GitHub.
Deberías moverte por la terminal sin dudar. Deberías entender qué es una solicitud HTTP y hacer una en Python.
Y deberías poder ejecutar una consulta SQL básica.
Si puedes hacer esas cosas, tienes la base.
La mayoría de las personas que se rinden nunca llegan aquí, y llegar aquí es genuinamente la parte más difícil porque es la menos emocionante.
Se vuelve más divertido a partir del Mes 2, porque desde aquí estás construyendo con IA.
Mes 2: Construye con API de LLM
Tu objetivo este mes: construir funciones reales impulsadas por IA utilizando API de modelos.
Al final, deberías sentirte cómodo escribiendo indicaciones que produzcan resultados confiables, obteniendo datos estructurados de un modelo, haciendo que el modelo llame a tus propias funciones, gestionando una conversación y manejando todo lo que pueda fallar.
Este es el núcleo de todo el trabajo. Todo lo demás después de esto se basa en ello.
Este es el mes en que empieza a sentirse real. Dejas de hacer configuración y empiezas a hacer que los modelos hagan cosas.
Tómate tu tiempo aquí.
La profundidad en el Mes 2 da más frutos que la profundidad en cualquier otro lugar de la guía.
Indicaciones que realmente funcionan
Hacer indicaciones no es preguntarle a un chatbot amablemente.
Es la habilidad de escribir instrucciones que produzcan resultados consistentes y confiables de un sistema que es fundamentalmente probabilístico.
Como ingeniero de IA, pasarás más tiempo aquí del que esperarías, y volverse bueno en esto es lo de mayor apalancamiento que puedes hacer este mes.
Mi elección: el tutorial interactivo de ingeniería de indicaciones de Anthropic en GitHub. Es el recurso más práctico que existe, dividido en capítulos con ejercicios reales que ejecutas contra la API de Claude.
Practicas escribir y corregir indicaciones tú mismo en lugar de leer sobre ello, lo que, si recuerdas el Error 2, es todo el punto.
Encuéntralo en el repositorio anthropics/prompt-eng-interactive-tutorial. Una vez que lo hayas trabajado, los documentos oficiales de ingeniería de indicaciones de Anthropic y OpenAI son la referencia a la que volverás.
En qué enfocarte: la diferencia entre un mensaje del sistema y un mensaje de usuario, y por qué esa diferencia importa.
Por qué la especificidad vence a la cortesía siempre.
Indicación de cadena de pensamiento, donde le pides al modelo que razone paso a paso antes de responder, lo que mejora mediblemente los resultados en cualquier cosa con lógica.
Usar ejemplos dentro de tu indicación, llamado indicación de pocos ejemplos, para mostrarle al modelo el formato que deseas.
Y desarrollar una sensación de cómo pequeños cambios en la redacción producen grandes cambios en la salida, lo que solo viene de hacerlo mucho.
Un ejercicio de construcción que enseña esto rápido: toma una tarea real, como resumir un documento o clasificar un comentario, y escribe cinco indicaciones diferentes para ella.
Ejecuta las cinco.
Compara las salidas una al lado de la otra. Verás inmediatamente cuánto impulsa el diseño de la indicación la confiabilidad, y esa lección se queda mejor que cualquier conferencia.
Salidas estructuradas
En una aplicación real, casi nunca quieres un párrafo de texto de vuelta de un modelo.
Quieres datos estructurados que tu código pueda analizar, almacenar y usar. Las salidas estructuradas resuelven esto al forzar al modelo a devolver datos que coincidan con un esquema que defines.
Esta es una de esas habilidades que separa una demostración de algo que realmente funciona dentro del software.
Mi elección: la biblioteca Instructor para Python, respaldada por los documentos oficiales de salida estructurada de OpenAI y Anthropic.
Instructor es la forma más limpia de obtener datos estructurados de cualquier modelo importante usando Pydantic, que es una biblioteca de Python para definir la forma de tus datos.
Funciona entre proveedores con el mismo código y se reintenta automáticamente cuando el modelo devuelve algo mal formado.
Está cerca de lo que muchos ingenieros en activo realmente usan, lo que hace que valga la pena aprenderlo en proyectos reales en lugar de una versión de juguete.
En qué enfocarte: definir un modelo de Pydantic que describa los datos que deseas, pasar ese esquema a la API y manejar el caso en que el modelo se niegue o devuelva algo inesperado.
Comprende la diferencia entre salidas estructuradas verdaderas, donde se aplica el esquema, y el modo JSON más flexible, donde no está garantizado.
Aquí tienes tu segundo artefacto para marcar, un patrón de indicación para la extracción estructurada confiable que funciona incluso antes de agregar una biblioteca encima.
Indicación: Extracción de datos estructurados
(Marco: Extractor FAG, por AI Guides)
1Tu trabajo: extraer datos estructurados del texto que te proporcione y devolverlos2como JSON limpio.34Qué hacer:5- Lee el texto de entrada con atención.6- Extrae solo los campos listados en la sección "Salida" a continuación.7- Si falta un campo en el texto, usa null. No adivines ni inventes.8- Devuelve solo el objeto JSON. Sin explicaciones, sin markdown, sin preámbulos.910Reglas:11- Cada valor debe poder rastrearse hasta algo en el texto de entrada.12- Fechas en formato YYYY-MM-DD. Números como números, no como cadenas.13- Si el texto es ambiguo, prefiere null antes que una respuesta incorrecta con seguridad.1415Salida: un objeto JSON con estos campos:16{17 "field_one": string o null,18 "field_two": número o null,19 "field_three": lista de strings o lista vacía20}2122Texto de entrada:23[PEGA EL TEXTO AQUÍ]
La nota sobre el fallo probado, porque te prometí la versión honesta: la primera vez que hagas esto, el modelo a veces envolverá el JSON en bloques de código markdown, o añadirá una frase amigable antes, y tu parser fallará.
Eso es normal. La solución es eliminar los bloques de código antes de parsear, y ser explícito en el prompt de que solo quieres el objeto JSON, que es lo que hace el patrón de arriba.
Una vez que te topes con esto y lo manejes, lo manejarás para siempre.
Tu objetivo de construcción: un analizador de recibos o facturas.
Aliméntalo con texto desordenado como "Factura 123, $45.99 por 3 widgets, vence el 30 de marzo" y obtén un objeto estructurado limpio con el número de factura, el monto, la cantidad de artículos y la fecha de vencimiento.
Esta es una herramienta pequeña genuinamente útil y una buena pieza para tu portafolio.
Llamada a herramientas
La llamada a herramientas es lo que convierte a un generador de texto en algo que puede tomar acciones: buscar en la web, consultar una base de datos, llamar a tu API, ejecutar código.
Es una de las habilidades más importantes en toda esta guía, y es la base de todo en el Mes 3.
El modelo mental que lo aclara: el modelo no ejecuta tus funciones.
Mira la conversación, decide que se debe usar una herramienta, y devuelve una solicitud estructurada nombrando la función y los argumentos.
Tu código ejecuta la función y le devuelve el resultado al modelo. El modelo es el que toma las decisiones. Tu código son las manos.
Mi recomendación: la guía de llamada a funciones de OpenAI y los documentos de uso de herramientas de Anthropic, léelos juntos.
Los conceptos son idénticos en ambas, la sintaxis difiere ligeramente, y ver ambas hace que el patrón subyacente sea obvio.
Luego trabaja con un ejemplo de notebook ejecutable, como el del cookbook de OpenAI, para que veas el ciclo completo de principio a fin en lugar de en partes.
En qué enfocarte: describir tus funciones claramente en un esquema, analizar la respuesta de llamada a herramientas del modelo, ejecutar la función y devolver el resultado, y manejar el caso en que el modelo decide que no se necesita ninguna herramienta.
La calidad de las descripciones de tus herramientas importa más de lo que los principiantes esperan, que es un tema que vuelve con fuerza en el Mes 3.
Tu objetivo de construcción: un pequeño asistente con tres herramientas, como get_weather, calculate y search_notes, donde search_notes solo busca en un diccionario fijo.
Conéctalas todas y observa cómo el modelo decide cuál llamar según lo que le preguntes.
En el momento en que lo veas elegir la herramienta correcta por sí solo, el concepto se fija permanentemente.
Estado de la conversación y streaming
Dos habilidades más pequeñas pero esenciales completan el mes.
Los modelos no tienen memoria entre llamadas. Una conversación es algo que gestionas enviando el historial completo de mensajes con cada solicitud.
Entender esto es fundamental, y sorprende a casi todos al principio.
Mi recomendación son los documentos de mensajes de OpenAI y Anthropic.
Concéntrate en cómo está estructurada la matriz de mensajes, por qué añades tanto los mensajes del usuario como las respuestas del modelo, qué sucede cuando superas la ventana de contexto, y las estrategias básicas para recortar mensajes antiguos.
Construye un chatbot de terminal simple de múltiples turnos que mantenga el historial y tenga un comando de reinicio. Es pequeño y enseña el concepto por completo.
Streaming significa mostrar la salida del modelo a medida que se genera, palabra por palabra, en lugar de hacer que el usuario espere a que termine todo.
Hace que las aplicaciones se sientan dramáticamente más rápidas.
Mi recomendación son los documentos oficiales de streaming de cualquiera de los proveedores, más el artículo claro de Simon Willison sobre cómo funciona el streaming internamente.
Concéntrate en configurar la opción de streaming, iterar sobre los fragmentos y ensamblar la respuesta completa a partir de las piezas.
Para cualquier cosa que usará una persona real, el streaming es casi siempre la opción correcta.
Nadie quiere mirar un spinner durante diez segundos.
Costo, fallos y una idea de seguridad
Tres cosas que separan un proyecto de hobby de algo que pondrías frente a usuarios.
Costo y tokens: los modelos cobran por token, que es aproximadamente tres cuartos de una palabra.
Los tokens de entrada y salida tienen precios diferentes.
Aprende a estimar lo que costará una solicitud antes de enviarla, mantén las páginas de precios de los proveedores marcadas, e interioriza una regla que ahorra dinero real: no uses el modelo más grande y caro para tareas simples.
Un modelo más barato suele ser más que suficiente, y la diferencia de costo a escala es enorme.
Manejo de fallos: las APIs fallan.
Se alcanzan límites de velocidad, las solicitudes se agotan, el modelo devuelve una salida mal formada.
Manejar esto con elegancia es lo que hace que algo esté listo para producción.
Aprende a capturar errores de límite de velocidad y reintentar con una demora creciente entre intentos, llamado backoff exponencial.
La biblioteca Tenacity en Python hace esto con un solo decorador.
Aprende a validar la salida del modelo antes de confiar en ella, y nunca dejes que una respuesta inesperada bloquee toda tu aplicación.
Inyección de prompts, brevemente: este es el principal riesgo de seguridad en las aplicaciones de LLM.
Ocurre cuando la entrada de usuario no confiable se combina con tus instrucciones, permitiendo que un usuario anule o secuestre lo que hace tu sistema.
No necesitas convertirte en un experto en seguridad este mes, pero necesitas saber que existe antes de lanzar cualquier cosa.
La guía de OWASP sobre esto es la referencia autorizada.
Las defensas principales: no confíes en la salida no validada del modelo para tomar acciones consecuentes automáticamente, y dale a tus herramientas el menor acceso que necesiten para hacer su trabajo.
Hito del Mes 2
Al final del mes, deberías ser capaz de escribir prompts que produzcan una salida confiable para una tarea determinada, obtener JSON estructurado de un modelo con Pydantic e Instructor, configurar la llamada a herramientas para que un modelo pueda ejecutar tus funciones de Python, transmitir una respuesta en tiempo real, gestionar el historial de conversaciones de múltiples turnos, estimar el costo de tokens de una solicitud antes de enviarla, manejar errores de API y salidas incorrectas sin bloquearse, y explicar qué es la inyección de prompts.
Eso es un conjunto de habilidades real y empleable por sí solo.
Muchas funciones de IA pagadas en producción hacen exactamente esto y nada más.
Pero el próximo mes es donde construyes lo que realmente te consigue un trabajo.
Mes 3: RAG y agentes, las habilidades que te consiguen trabajo
Tu objetivo este mes: construir sistemas que permitan a los modelos responder desde tus documentos en lugar de solo sus datos de entrenamiento, y construir sistemas que tomen múltiples pasos por sí solos.
Estas dos habilidades, recuperación y agentes, son las habilidades prácticas más demandadas en la ingeniería de IA en este momento.
Casi todos los casos de uso reales de empresas, desde bots de soporte hasta herramientas internas de conocimiento y análisis de documentos, se basan en ellas.
He comprimido lo que muchas hojas de ruta distribuyen en dos meses en uno, porque no necesitas dominar cada variación avanzada para ser empleable.
Necesitas construir un sistema de recuperación sólido y un agente sólido, entender por qué cada pieza está ahí, y ser capaz de depurarlos cuando fallen.
Ese es el estándar. Vamos a alcanzarlo.
RAG, en español sencillo primero
RAG significa generación aumentada por recuperación.
Quita la jerga y es simple: le das al modelo una biblioteca para buscar cosas, para que no tenga que haber memorizado todo, y para que pueda responder preguntas sobre tus documentos específicos.
El flujo es: tomas tus documentos, los divides en fragmentos, conviertes cada fragmento en una lista de números que captura su significado, y los almacenas.
Cuando un usuario hace una pregunta, conviertes su pregunta en números de la misma manera, encuentras los fragmentos cuyos números están más cerca, y le entregas esos fragmentos al modelo junto con la pregunta.
El modelo responde usando lo que le diste. Eso es RAG. Todo lo demás es refinamiento.
Construyamos las piezas.
Embeddings
Un embedding es un fragmento de texto convertido en una larga lista de números que representa su significado.
La propiedad útil: el texto que significa cosas similares termina con números similares, cerca unos de otros en este espacio numérico.
Esa cercanía es lo que hace posible la búsqueda por significado, que es el motor de RAG.
Mi recomendación para construir la intuición: la introducción intuitiva a los embeddings de texto del blog de Stack Overflow, que se centra en el modelo mental en lugar de las matemáticas, más la guía de embeddings de OpenAI cuando estés listo para generarlos en código.
Concéntrate en entender qué es un vector conceptualmente, por qué el texto similar produce vectores similares, y aproximadamente cómo se mide la distancia entre dos de ellos.
No necesitas las matemáticas detrás de cómo se producen los embeddings. Necesitas saber cómo usarlos.
Una construcción pequeña que enseña esto completamente: toma 20 oraciones sobre temas relacionados, convierte cada una en un embedding, y escribe una pequeña función que, dada una nueva oración, devuelva las tres más similares de tu conjunto.
Eso es RAG en miniatura. Una vez que hayas construido esto, la versión completa es solo la misma idea a escala.
Fragmentación (Chunking)
Tus documentos son demasiado grandes para incrustarlos enteros, así que los divides en fragmentos antes de incrustarlos.
Cómo fragmentes controla directamente qué tan bien tu sistema encuentra la información correcta.
Incluso una configuración de recuperación perfecta falla si los fragmentos subyacentes son malos.
Mi recomendación: comienza con el RecursiveCharacterTextSplitter de LangChain, con un tamaño de fragmento de alrededor de 500 caracteres y una superposición de alrededor de 50.
Esa superposición importa, porque evita que pierdas significado en el límite donde termina un fragmento y comienza el siguiente.
Este es el valor predeterminado sensato que te da una línea base funcional.
La compensación principal que debes tener en cuenta: fragmentos demasiado grandes pierden precisión, fragmentos demasiado pequeños pierden contexto.
Comienza con el valor predeterminado, luego ajusta según lo que tu recuperación esté haciendo mal.
Bases de datos vectoriales
Una vez que tienes embeddings, necesitas un lugar para almacenarlos y buscarlos rápidamente. Eso es lo que hace una base de datos vectorial.
Mi recomendación para aprender: Chroma. Se ejecuta localmente sin necesidad de configurar infraestructura, que es exactamente lo que quieres mientras aprendes.
No necesitas escala en la nube gestionada todavía, y agregarla temprano solo te da más cosas que configurar y que se rompan.
Chroma te permite concentrarte en los conceptos.
Encuéntralo en docs.trychroma.com.
Aprende a crear una colección, insertar embeddings junto con metadatos como la fuente y la sección, consultar por similitud para obtener las mejores coincidencias, y filtrar por metadatos en el momento de la consulta.
No necesitas entender los algoritmos de indexación subyacentes. Necesitas usarlos.
Cuando eventualmente necesites escala de producción, pgvector es el siguiente paso natural si tu aplicación ya usa una base de datos Postgres, y hay opciones gestionadas cuando quieras que alguien más lo ejecute.
Pero eso es una preocupación del Mes 4 o del trabajo. Por ahora, Chroma, localmente, es suficiente.
Haciendo que la recuperación sea realmente buena
La búsqueda básica por similitud te da una demostración.
Unos pocos refinamientos te dan algo que funciona de manera confiable, y saber esto es lo que separa a las personas que copiaron un tutorial de las personas que entienden el sistema.
Filtrado de metadatos: etiqueta cada fragmento con información útil cuando lo almacenes, como el archivo fuente, la fecha, la sección o la categoría.
Luego filtra en esos en el momento de la consulta. Esta es la diferencia entre un juguete y un sistema donde un usuario puede preguntar "muéstrame solo los resultados del informe del Q4" y realmente obtenerlos.
Reordenamiento (Reranking): tu primera búsqueda es rápida pero aproximada.
Un reordenador toma los primeros resultados y los vuelve a puntuar para determinar la relevancia real para la pregunta, lo que mejora notablemente la calidad con un pequeño costo de velocidad.
El patrón es: recupera un conjunto amplio rápidamente, luego reordena hasta los mejores. Los documentos de reordenamiento de Cohere son el lugar más limpio para aprender esto, y a menudo es una línea para agregar.
Depuración de la recuperación, porque la mayoría de los fallos de RAG son fallos de recuperación, no fallos del modelo.
Cuando tu sistema da una mala respuesta, el modelo generalmente no es el problema.
La recuperación le entregó los fragmentos incorrectos.
Aprende los modos de fallo comunes: la pregunta y el fragmento relevante no coinciden en el espacio numérico aunque la información esté ahí (se puede solucionar reescribiendo la consulta), la información relevante está dividida en dos fragmentos (se puede solucionar con más superposición), o el fragmento correcto existe pero no llegó a los mejores resultados (se puede solucionar recuperando más, luego reordenando).
Cuando una respuesta sea incorrecta, verifica qué se recuperó antes de culpar al modelo. Este hábito te ahorrará una enorme frustración.
Fundamentación y citas: un buen sistema RAG no solo responde, sino que te dice de dónde vino la respuesta, lo que genera confianza y facilita enormemente la depuración.
Pasa la información de la fuente de cada fragmento a tu prompt, e instruye al modelo para que la cite.
Aquí está tu tercer artefacto, el prompt de fundamentación que mantiene honesto a un sistema RAG.
Este es el que marcaría por encima de todos los demás, porque es la diferencia entre un sistema que inventa cosas y uno en el que puedes confiar.
Prompt: Respuesta RAG fundamentada
(Marco: FAG Grounding, de AI Guides)
1Tu trabajo: responder la pregunta del usuario usando solo el contexto proporcionado.23Qué hacer:4- Lee los fragmentos de contexto a continuación. Cada uno tiene una etiqueta de fuente.5- Responde la pregunta usando solo la información encontrada en el contexto.6- Después de cada afirmación, cita la etiqueta de fuente de la que proviene, como [fuente: nombre_archivo, p.3].7- Si el contexto no contiene la respuesta, di exactamente:8 "No tengo suficiente información en los documentos proporcionados para responder eso."910Reglas:11- Nunca uses conocimiento de fuera del contexto proporcionado.12- Nunca adivines. Nunca llenes vacíos con lo que suene plausible.13- Si el contexto responde parcialmente la pregunta, responde esa parte y di14 claramente qué falta.1516Contexto:17[PEGA LOS FRAGMENTOS RECUPERADOS CON ETIQUETAS DE FUENTE AQUÍ]1819Pregunta:20[PREGUNTA DEL USUARIO AQUÍ]
Esa instrucción de "di exactamente esto cuando no sepas" está haciendo un trabajo pesado. Es la forma más efectiva de reducir las alucinaciones en un sistema de recuperación, porque le da al modelo una forma aprobada de admitir ignorancia en lugar de inventar una respuesta para parecer útil.
Tu construcción de RAG
Usa un framework para unir esto en lugar de construir cada pieza desde cero.
Mi recomendación para un primer sistema RAG es LlamaIndex, que está construido con la búsqueda como prioridad y te da un pipeline funcional con poco código.
LangChain es la otra opción principal y brilla más para el trabajo de agentes de múltiples pasos que viene a continuación, así que lo conocerás en un momento.
Tu objetivo de construcción, y esta es una pieza real de portafolio: una aplicación de "chatea con tus documentos".
Ingiere de 10 a 20 PDFs o archivos de texto, tus propias notas o un conjunto de documentos de producto funcionan bien, construye algo que tome una pregunta, recupere los fragmentos más relevantes con reordenamiento, y devuelva una respuesta citada.
Ponle una interfaz simple.
Este es el proyecto que hace que los gerentes de contratación te tomen en serio, porque es exactamente el tipo de cosas por las que las empresas están pagando para que se construyan ahora mismo.
Agentes
A mitad del mes, cambia a agentes.
Un agente suena a magia y es genuinamente simple una vez que lo ves: es un bucle donde el modelo decide repetidamente el siguiente paso, lo toma usando una herramienta, mira el resultado, y decide de nuevo, hasta que la tarea está hecha.
El modelo mental: un agente es un bucle while con un modelo tomando las decisiones de ramificación.
El pensamiento ocurre en el prompt. La ramificación es el modelo eligiendo qué herramienta usar. La acción es tu código ejecutando esa herramienta.
Todo lo demás es fontanería. Una vez que eso encaja, incluso los frameworks de agentes complicados se vuelven legibles.
Mi recomendación, y leería esto antes de escribir una sola línea de código de agente: "Building Effective Agents" de Anthropic.
Es el escrito más claro sobre cómo funcionan los agentes en la práctica, del equipo que construye los modelos.
Combínalo con un curso práctico de framework cuando estés listo para construir, como la introducción a LangGraph, que es el framework más utilizado para orquestar agentes.
En qué enfocarte: el bucle de percibir, decidir, actuar, observar, y cómo sabe cuándo detenerse.
Qué sucede cuando una llamada a herramienta falla dentro del bucle. Cómo escribir descripciones de herramientas que el modelo pueda usar realmente, porque una herramienta descrita vagamente se llama incorrectamente o se ignora.
Y gestionar el estado, que es la memoria compartida que fluye a través del agente mientras trabaja.
El ejercicio más valioso de este mes: construye un pequeño agente desde cero sin ningún framework, usando solo la API del modelo directamente.
Dale tres herramientas, un objetivo y un bucle. Esto te enseña lo que los frameworks están ocultando, y hace que cada framework que toques después tenga sentido.
Haz esto antes de tocar LangGraph.
Cuándo no usar un agente
Esta es una de las habilidades más pasadas por alto en el campo, y saberlo te marca como alguien con criterio en lugar de alguien que persigue lo brillante.
Los agentes son emocionantes, y también son más lentos, más caros, menos predecibles y más difíciles de depurar que los enfoques más simples.
Optar por lo más simple que funcione es una señal de que sabes lo que estás haciendo.
El marco de decisión, vale la pena memorizarlo: usa una sola llamada al modelo si la tarea cabe en un prompt con el contexto correcto.
Usa un flujo de trabajo fijo, una cadena de pasos que defines, si los pasos son predecibles.
Usa un agente solo cuando el número de pasos sea genuinamente impredecible y necesite que el modelo decida dinámicamente.
Una cadena de tres llamadas fijas siempre será más rápida, más barata y más fácil de depurar que un agente que podría hacer tres llamadas. Reserva los agentes para tareas genuinamente abiertas.
Entre una sola llamada y un agente completo hay un terreno intermedio grande y productivo: los flujos de trabajo.
Encadenamiento, donde la salida de una llamada alimenta la siguiente.
Enrutamiento, donde clasificas la entrada y la envías a un manejador especializado.
Paralelización, donde ejecutas varias llamadas a la vez y las combinas.
La mayoría de los problemas reales se resuelven mejor con un flujo de trabajo, no con un agente, y el artículo de Anthropic sobre agentes cubre bien estos patrones.
Evaluaciones, brevemente pero en serio
Necesitas saber si tu sistema realmente funciona, no solo si funcionó en los dos ejemplos que probaste manualmente.
Para eso sirven las evaluaciones. Construye un pequeño conjunto de 20 a 30 entradas representativas con salidas esperadas o una rúbrica de puntuación, y ejecuta tu sistema contra todas ellas cada vez que cambies un prompt, cambies un modelo o ajustes tu recuperación.
Herramientas como DeepEval para uso general y Ragas para RAG específicamente hacen que esto sea manejable.
La mentalidad que importa más que la herramienta: cada cambio de prompt o intercambio de modelo que hagas sin ejecutar evaluaciones es una apuesta.
Las personas que lanzan IA confiable ejecutan evaluaciones constantemente, y comenzar este hábito ahora, incluso de manera pequeña, te pone por delante de muchas personas que ya trabajan en el campo.
Hito del Mes 3
Al final del mes, deberías ser capaz de explicar qué es un embedding y por qué el texto similar produce vectores similares, fragmentar un documento de manera sensata, almacenar y consultar embeddings en una base de datos vectorial con filtrado de metadatos, agregar reordenamiento para mejorar los resultados, depurar un fallo de recuperación en lugar de culpar al modelo, construir un pipeline RAG completo que devuelva respuestas fundamentadas y citadas, implementar un bucle de agente desde cero, decidir correctamente si una tarea necesita una sola llamada, un flujo de trabajo o un agente, y ejecutar una evaluación básica para verificar tu trabajo.
Ese es el núcleo empleable.
Si los Meses 1 a 3 son sólidos, puedes construir las cosas para las que las empresas están contratando.
El Mes 4 se trata de demostrarlo y cobrar.
Mes 4: Lánzalo, muéstralo, consigue trabajo
Tu objetivo este mes: toma todo lo que has construido y hazlo real, luego conviértelo en un trabajo o trabajo remunerado.
Aquí es donde la mayoría de la gente se estanca.
Pueden construir una demostración pero no pueden lanzar algo que sobreviva al uso real, y no pueden convertir sus habilidades en ingresos.
Este mes soluciona ambas cosas. Es más corto en nuevos conceptos y más pesado en hacer, porque en este punto hacer es lo que importa.
Suficiente despliegue para ser peligroso
No necesitas convertirte en un experto en infraestructura.
Necesitas poder poner una aplicación de IA funcional en algún lugar donde personas reales puedan usarla, sin que se caiga o te lleve a la bancarrota.
El conocimiento mínimo viable: aprende suficiente Docker para empaquetar tu aplicación para que se ejecute igual en todas partes, lo que elimina el problema de "funciona en mi máquina".
Aprende a desplegar ese contenedor en algún lugar.
Y aprende los conceptos básicos de costo y confiabilidad que evitan que un error se convierta en un desastre: establece límites de gasto duros en tus cuentas de API, agrega almacenamiento en caché para no pagar dos veces por la misma solicitud, y agrega limitación de velocidad para que un solo usuario no pueda aumentar tu factura.
La guía oficial de inicio de Docker cubre el empaquetado.
Para el lado específico de costos de IA, los movimientos principales son almacenar en caché solicitudes idénticas, usar modelos más baratos donde sean suficientemente buenos, y establecer un límite de gasto mensual duro para que un bucle descontrolado no pueda costarte $500 de la noche a la mañana.
También quieres observabilidad básica, que es una palabra elegante para poder ver lo que está haciendo tu aplicación.
Las aplicaciones de LLM tienen un problema específico: el modelo puede devolver una respuesta perfectamente exitosa que también es inútil o incorrecta, y el monitoreo normal no detectará eso.
Una herramienta como Langfuse rastrea cada llamada al modelo, mostrándote el prompt, la respuesta, el costo de tokens y la latencia, lo que facilita mucho la depuración y el control de costos.
Configura esto en un proyecto para que entiendas el patrón.
No inviertas demasiado aquí.
Una aplicación, desplegada correctamente, con controles de costos y rastreo básico, te enseña todo lo que necesitas y te da algo real que mostrar.
La profundidad en el despliegue puede llegar en el trabajo.
La parte que todas las demás hojas de ruta omiten: convertir proyectos en un trabajo.
Has construido tres proyectos reales. Ahora haz que trabajen para ti, porque un gran proyecto que nadie ve no hace nada por tu carrera.
Tu portafolio son tres proyectos desplegados, cada uno con un README que hace un trabajo real.
Y aquí está el movimiento que casi nadie hace, el que te diferenciará: en cada README, incluye una sección sobre lo que salió mal y lo que harías diferente.
La mayoría de los portafolios pretenden que todo funcionó perfectamente, lo que se lee como deshonesto o superficial.
Un README que dice "aquí es donde mi primer enfoque falló, aquí está lo que aprendí, aquí está cómo lo solucioné" señala exactamente el criterio que los empleadores dijeron que ahora están evaluando.
Es la ventaja del cambiador de carrera de la introducción, hecha visible.
Nadie espera que un cambiador de carrera tenga un proyecto perfecto. Están impresionados por alguien que claramente entiende su propio trabajo lo suficientemente profundo como para criticarlo.
Estructura cada README así: el problema que resuelve el proyecto, quién lo usaría, el enfoque que tomaste y por qué, lo que salió mal y lo que aprendiste, y cómo ejecutarlo.
Cinco secciones.
Eso es un mejor portafolio que el que tiene la mayoría de la gente con un título en ciencias de la computación.
El movimiento del currículum y el perfil: no necesitas fingir que tienes años de experiencia.
Necesitas una línea clara que diga lo que puedes hacer.
Algo como "Construyo aplicaciones de LLM de producción: sistemas RAG, agentes e integraciones de API. Aquí hay tres que he lanzado."
Luego enlaza los proyectos. Tu carrera existente es un activo, no algo que ocultar.
"Ex-[tu campo] que ahora construye sistemas de IA" es una historia más fuerte que "desarrollador junior", porque viene con el conocimiento del dominio y el criterio que le falta a un junior puro.
Si vienes de finanzas, entiendes los problemas financieros que una IA podría resolver.
Si vienes del sector salud, igual. Aprovéchalo.
Construir en público como tu canal de oportunidades: durante todo este mes, sigue publicando lo que construyes y lo que aprendes.
Las mejores oportunidades que he visto han llegado a personas que eran visibles, no a quienes enviaron currículums en silencio a 500 ofertas.
Escribe sobre tus proyectos. Comparte el error que corregiste. El efecto compuesto es real, y a estas alturas ya tienes trabajo real que compartir, así que es más fácil que en el Mes 1.
Elige una dirección
Para el Mes 4, puedes orientar tus habilidades hacia lo que se ajuste a tus objetivos. Tres direcciones, elige una para profundizar en lugar de dispersarte.
El camino de ingeniero de producto de IA, ideal si quieres un trabajo en una startup rápido: construyes productos impulsados por IA que los usuarios reales tocan.
Ya tienes la mayor parte de esto de los Meses 1 a 3.
Profundiza en la creación de aplicaciones completas y pulidas, y en el aspecto de producto, es decir, cómo maneja la aplicación cuando el modelo se equivoca, cómo muestra los estados de carga, cómo los usuarios dan su opinión.
Lanza dos o tres cosas que la gente pueda probar realmente.
El camino de ML aplicado, ideal si quieres roles técnicos más profundos: ve más allá de las llamadas a la API hacia el ajuste fino (fine-tuning), cuándo ajustar fino versus simplemente mejorar el prompt, ejecutar modelos de código abierto localmente con una herramienta como Ollama, y optimización de inferencia.
El marco de decisión que debes conservar: comienza con prompting, añade recuperación (retrieval) si el modelo necesita tus datos específicos, y solo ajusta fino cuando el prompting y la recuperación genuinamente no puedan alcanzar la calidad que necesitas.
El ajuste fino a menudo se intenta demasiado pronto.
El camino de automatización con IA, ideal si quieres ganar dinero con negocios de inmediato: concéntrate en automatizar flujos de trabajo empresariales reales, encadenando IA a través de herramientas como correo electrónico, CRM, documentos y hojas de cálculo.
Herramientas como n8n para flujos de trabajo visuales y LangGraph para los que requieren mucho código.
Una construcción vendible aquí: un sistema de calificación de leads que importa clientes potenciales, utiliza un modelo para investigar y puntuar cada uno, redacta un acercamiento personalizado y registra todo.
Las empresas pagan dinero real por exactamente esto.
Hito del Mes 4
Para final de mes, deberías tener una aplicación de IA desplegada con controles de costos adecuados, tres proyectos de portafolio cada uno con un README honesto, un discurso claro de una línea sobre lo que construyes, un rastro visible de trabajo en público, y una dirección elegida en la que estás profundizando.
En ese punto, ya no eres "alguien aprendiendo IA". Eres alguien que lanza sistemas de IA, que es lo que el mercado está pagando.
La parte honesta
Te dije al principio que no te iba a vender una fantasía, así que aquí está la versión directa antes de las cifras de dinero.
Cuatro meses de trabajo enfocado te hacen empleable a nivel junior o listo para aceptar trabajo freelance. No te convierten en un ingeniero senior.
El nivel senior proviene de años lanzando cosas reales bajo restricciones reales, y ninguna guía comprime eso.
Lo que cuatro meses te compran es la capacidad de construir, lanzar y desplegar sistemas de IA que resuelven problemas reales, que es un lugar genuinamente valioso y genuinamente contratable.
Esto asume trabajo real, aproximadamente de 15 a 20 horas por semana, construyendo de verdad y no solo mirando.
Si solo puedes dedicarle 7 horas a la semana, este es un camino de 8 meses, y eso está completamente bien.
El cronograma se estira, el destino no cambia. Lo que mata a la gente no es un ritmo lento. Es detenerse.
La constancia vence a la intensidad aquí cada vez.
Y todo se basa en un comportamiento de la sección de errores: construye, no solo mires.
Cada mes tiene un proyecto. Haz los proyectos. Una persona que construye cuatro proyectos toscos en cuatro meses es contratable.
Una persona que mira cuatro meses de tutoriales perfectos no lo es. Ese es todo el juego.
El dinero, con fuentes
Ahora los números que realmente quieres, todos actuales y todos con fuente, porque las afirmaciones de sueldos vagas son cómo estas guías pierden credibilidad.
A junio de 2026, Glassdoor sitúa el salario promedio de ingeniero de IA en EE. UU. en aproximadamente $143,500, con un rango típico de alrededor de $115,000 en el percentil 25 a $181,000 en el percentil 75, y los que más ganan reportados hasta alrededor de $223,000.
Los ingenieros de IA senior promedian alrededor de $285,000, con un rango típico de aproximadamente $221,000 a $375,000, lo que muestra lo pronunciado que es el salto una vez que tienes experiencia real.
Esas son las cifras de Glassdoor basadas en salarios reportados.
Los reclutadores que colocan a personas en trabajo genuino de producción de IA reportan salarios base de nivel medio agrupándose entre $155,000 y $200,000, basados en ofertas firmadas en lugar de encuestas, lo que coincide con el rango de Glassdoor y te da una segunda lectura independiente.
Y el contexto de mercado más amplio del Barómetro de PwC 2026, con el que abrí: los trabajos con habilidades de IA crecen aproximadamente ocho veces más rápido que el mercado general, una prima salarial del 62% para habilidades de IA, y los requisitos de título universitario están cayendo más rápido exactamente en estos roles.
Esos no son de un hilo de hype. Son de un análisis de más de mil millones de anuncios de empleo.
Las tarifas de freelance y consultoría varían demasiado para citarlas con precisión sin engañarte, así que diré solo esto: las tarifas para implementación de RAG, creación de agentes e integración de LLM son altas, y alguien que cambia de sector con tres proyectos sólidos desplegados y un discurso claro puede empezar a cobrar por ese trabajo mucho antes de conseguir un puesto a tiempo completo.
Los proyectos son la prueba. Constrúyelos y las opciones de ingresos se abren.
Empieza esta semana
Esto es lo que realmente haría, hoy, si fuera tú.
Elige el proyecto de Python del Mes 1, la pequeña herramienta de línea de comandos. Abre un editor de código.
Empieza el primer conjunto de problemas de CS50P. Configura el prompt del compañero de aprendizaje para que la IA te guíe a través de las partes frustrantes.
Crea un repositorio en GitHub y pon tu primer archivo feo en él. Esa es toda la primera semana.
No esperes hasta sentirte listo, porque la preparación llega después de empezar, no antes.
No planifiques los cuatro meses con lujo de detalle antes de escribir una línea de código, porque el plan ya está aquí y la planificación es solo una forma cómoda de evitar empezar.
La brecha entre aprender y construir es donde la gente pierde un año. Ciérrala esta semana.
Cuatro meses de trabajo real cambian genuinamente lo que es posible para ti.
La puerta está más abierta de lo que ha estado en cualquier momento anterior, la barrera del título universitario está cayendo, y el mercado está pagando más por estas habilidades que por casi cualquier otra cosa en tecnología.
Tienes la guía. La única variable que queda es si construyes.
Guarda esto y vuelve a consultarlo cada mes a medida que avances. Lo mantendré actualizado a medida que las herramientas y los números cambien.
Sigue a @free_ai_guides para las actualizaciones ❤️
