Qué es un AI Engineer (y mi ruta desde Frontend)
Mi perfil dice Frontend Engineer. La semana pasada pasé tres horas midiendo VRAM, comparando cuantizaciones y peleándome con el max-model-len de un servidor de inferencia. No hubo un momento en el que decidí cambiar de carrera: en algún punto entre usar AI todos los días y querer entender por qué se comporta como se comporta, el trabajo dejó de ser el mismo.
Este post es la respuesta a la pregunta que más me hacen: qué es un AI Engineer de verdad, y cómo se hace esa transición desde el frontend. Con lo que sé hoy y con lo que todavía me falta.
Qué es un AI Engineer (definición operativa)
No es un investigador de ML. No es alguien que usa ChatGPT. Es quien construye sistemas que funcionan con modelos: decide qué contexto entra, diseña las tools, mide si mejoró, controla el costo y opera la inferencia. El modelo es una pieza más; el trabajo está en todo lo que lo rodea.
Esa distinción tiene nombre: modelo y harness. El modelo es el motor; el harness es el coche (loop, tools, contexto, permisos, evals, observabilidad). Anthropic lo dice sin rodeos: "los agentes son simplemente LLMs usando tools basados en el feedback del entorno, en un loop", y recomiendan empezar por lo simple antes de añadir complejidad. - Source: Building effective agents - Anthropic
Si quieres el vocabulario completo, lo dejé en el diccionario de 36 términos. Aquí voy a lo que importa para decidir si esto es para ti.
Las 5 habilidades que sí importan (y las que no)
| Importa | No importa tanto |
|---|---|
| Leer documentación y medir en vez de opinar | Entrenar un modelo desde cero |
| Diseñar la interfaz del agente (tools, contratos, errores) | Matemática avanzada (salvo si vas a fine-tuning o inferencia profunda) |
| Evaluar: saber si tu sistema mejoró o empeoró | Memorizar frameworks: cambian cada seis meses |
| Operar costos y latencia como features | Escribir el prompt perfecto |
| Escribir contexto: qué ve el modelo y qué no | Tener el título de "AI" en el perfil |
Las dos primeras columnas son lo que veo en los equipos que funcionan. La derecha es lo que sobra en las conversaciones.
Mi ruta real (Frontend → AI Engineer)
No hubo un curso que me convirtió. Fueron cuatro fases que todavía estoy recorriendo.
1. Usar AI a diario. Claude Code, skills, MCP, agents en el editor. Esta fase no me hizo AI Engineer, pero me dio intuición de cómo se comportan los modelos: cuándo aciertan, cuándo inventan, qué contexto necesitan.
2. Construir. El salto real es dejar de usar sistemas con AI y empezar a construirlos: escribir tools, montar el loop, manejar el estado. Aquí aprendí que un agente es un loop, no un prompt largo.
3. Operar. Evals, guardrails, trazas, costos. Esta es la fase que separa una demo de un producto, y la que casi nadie documenta.
4. Inferencia. Mi foco actual: entender el motor. TTFT, tokens/s, VRAM, cuantización, serving. Inference Engineering es el hueco que veo en casi todos los perfiles "AI" que conozco, y por eso me estoy moviendo hacia ahí.
Lo que me faltó al empezar: no saber medir. Pasé meses "probando" cosas sin evals, así que cada cambio era una opinión. Y lo que sigo aprendiendo: leer papers sin miedo y no confundir entusiasmo con evidencia.
El plan de 12 meses que estoy ejecutando
No es un roadmap para presumir; es el que uso para decidir qué estudiar cada semana.
| Trimestre | Objetivo | Cómo lo mido |
|---|---|---|
| 1 | Bases + construir agentes (harness, contexto, tools) | Un agente propio funcionando con evals básicas |
| 2 | Operar (evals serias, guardrails, observabilidad, costos) | Factura y latencia antes/después de rutear modelos |
| 3 | Inferencia (local, cuantización, serving) | Un modelo corriendo local con números publicados |
| 4 | Producción (varios modelos, canary, autoscaling) | El sistema de la serie AI corriendo de punta a punta |
El criterio de éxito no es "saber mucho" sino poder demostrarlo con números. Eso es lo que estoy publicando, una pieza por semana.
Lo que NO voy a hacer
- No voy a pretender ser investigador de ML. Sé leer un paper y lo suficiente de matemática para no confundirme; no voy a reimplementar atención desde cero, y no hace falta para el trabajo que quiero.
- No voy a reescribir frameworks a mano. Entiendo el loop por dentro y uso librerías donde ahorran tiempo.
- No voy a vender humo. Si algo no lo probé, lo digo. Si me equivoqué, lo corrijo en público.
Si empiezas mañana, esto haría yo (5 pasos)
- Elige un problema tuyo y resuélvelo con un LLM. No un tutorial: algo que uses.
- Mide desde el día uno. Aunque sea a mano: ¿funcionó o no? Guarda los casos.
- Aprende el ciclo del agente antes que los frameworks: decidir, ejecutar, observar, parar.
- Escribe contexto y tools como si fueran API pública. Ahí está el trabajo real.
- Publica lo que aprendes, incluidos los errores. Es la forma más rápida de encontrar a quien sabe más que tú.
Y si quieres el camino largo y profundo (matemática, ML desde cero), una referencia honesta es AI Engineering from Scratch; si quieres el camino aplicado en inglés, AI Hero. Este blog es el tercero: el de alguien que lo está haciendo en sus productos y publica los números.
¿Tú en qué fase estás: usas AI, construyes, operas o ya estás en inferencia? Cuéntame en los comentarios, porque la serie la voy ajustando con lo que ustedes preguntan.