Adoptar AI engineering no es elegir un modelo. Es decidir cuánta autonomía darle a un componente probabilístico, qué controles la hacen aceptable y qué partes construir, comprar o no tener. Las malas decisiones no se notan en la demo; se notan en la primera factura inesperada o el primer incidente.
Esta lección reúne el curso en una guía de decisión para líderes técnicos. Los tres productos del curso sirven de ejemplo de decisiones concretas, no de recetas universales.
Arquitecturas por nivel de madurez
Los niveles no son etapas obligatorias: cada uno agrega costos que solo se justifican si el problema existe. La mayoría de las aplicaciones reales viven en los niveles 1 a 3.
| Nivel | Quién decide la acción | Control principal | Cuándo |
|---|---|---|---|
| 1. App → LLM | nadie (no hay acciones) | validación de salida | generar, resumir, extraer |
| 2. Workflow | el código | el diseño de los pasos | procesos conocidos, RAG |
| 3. Agente | el modelo | el prompt | exploración de bajo riesgo |
| 4. Agente + harness | el modelo, acotado | límites del loop | agentes sin supervisión constante |
| 5. Harness gobernado | el modelo, gobernado | políticas, aprobación, sandbox | sistemas reales |
| 6. Multi-agente gobernado | varios modelos | lo anterior + gates entre roles | separación de funciones medida |
El salto del nivel 2 al 3 es el que más cambia el riesgo: ya no escribes la secuencia de acciones, diseñas el espacio de acciones posibles (De la aplicación con LLM al agente). Un sin políticas ni aislamiento es confiable, no seguro.
El ecosistema y la decisión de construir o comprar
| Categoría | Para qué sirve | Ejemplos |
|---|---|---|
| Agent frameworks | no reescribir loop, tools y handoffs | LangGraph, OpenAI Agents SDK, Pydantic AI |
| Coding agents | aplicar un agente a un repositorio | Claude Code, Codex, OpenHands |
| Model gateways | muchos modelos detrás de una API | OpenRouter, LiteLLM, Vercel AI Gateway |
| Observabilidad | reconstruir trayectorias y costos | OpenTelemetry, Langfuse, Arize Phoenix |
| Evals | medir calidad y regresiones | promptfoo, DeepEval, Inspect AI, Ragas |
| Sandbox | ejecutar código sin comprometer el host | gVisor, Firecracker, E2B, Modal |
| Durable execution | flujos que sobreviven a caídas | Temporal, Restate, DBOS |
Los tres productos del curso decidieron distinto, cada uno con una razón explícita:
Para CTOs
Antes de construir, usa la regla de priorización de docket (docs/adr/0005-prioritization-ruling-viable-vs-overengineering.md): ¿lo pide una necesidad medida en este sistema, o solo es buena práctica en otro lado? Con esa regla docket descartó OpenTelemetry: correcto a escala de plataforma, innecesario para un host y un operador. Construye lo diferencial o lo que ningún proveedor puede darte bajo tus restricciones (datos, cumplimiento, punto de control); adopta el resto y documenta qué capas dejas fuera.
Dónde debería detenerse el sistema
La pregunta útil no es "¿el modelo debería negarse?", sino "¿qué capa lo detiene?". Un compite con un texto que se presenta como requisito; un clasificador puede escalarlo a aprobación; una red restringida a los registries lo vuelve imposible.
Prevenir Contener Detectar / recuperar
mínimo privilegio sandbox traza
secretos fuera red restringida auditoría
políticas, aprobación presupuestos, límites cancelación, rollback
El prompt ayuda en las tres; no garantiza ninguna.
Lo mismo vale para un loop que corre todo el fin de semana: solo un acumulado lo detiene, no los límites por turno. Detalle en Gobernanza y human-in-the-loop y Sandboxing y seguridad de agentes.
Anti-patrones
- Confiar solo en el system prompt. Úsalo para el caso normal; pon políticas en el camino de ejecución para el peor caso.
- Secretos al alcance del modelo. Terminan en trazas o commits; mantenlos dentro de la herramienta o del runner.
- Sin presupuesto ni timeouts. Pon topes por llamada, turno, tarea y proyecto.
- Reintentos sin . Dos cobros, dos deploys. Ver Ejecución durable de agentes.
- Multi-agente porque suena avanzado. Agrega un rol solo cuando aporta independencia real y una eval lo justifica (Sistemas multi-agente).
- RAG o base vectorial por moda. Si cabe en el contexto, pégalo.
- Evaluar solo el texto final. Evalúa trayectorias; calibra a los jueces contra humanos.
- Maquinaria sin cablear. Una función testeada que nada en el camino real llama.
Tabla de decisión
| Necesidad | Capa | Pregunta antes de adoptar |
|---|---|---|
| Workflow determinista | orquestación | ¿los pasos se conocen de antemano? |
| Agente | agente | ¿la tarea exige que el modelo elija los pasos? |
| Controlar tools | gobernanza | ¿hay un único punto antes de cada ejecución? |
| Ejecutar código no confiable | ejecución | ¿qué aísla: archivos, red, credenciales, kernel? |
| Evaluar calidad | calidad | ¿tengo dataset representativo y oráculos? |
| Controlar costos | economía | ¿cuál es mi fuente de verdad del costo? |
| Recuperar ejecuciones | confiabilidad | ¿los efectos se pueden repetir sin daño? |
| Prevenir exfiltración | seguridad | ¿qué flujo combina datos privados, contenido no confiable y salida externa? |
Ninguna fila dice "escribir un mejor prompt". Un buen prompt mejora casi todas; no reemplaza ninguna.
Roadmap hacia senior AI engineer
Organizado por capacidades, no por herramientas, que cambian.
| Nivel | Qué dominar | Sabes que lo dominas cuando… |
|---|---|---|
| 1. Software | transacciones, concurrencia, idempotencia | diseñas un reintento que no duplica efectos |
| 2. LLMs | tokens, contexto, tool calling | escribes un tool call con la API cruda |
| 3. Apps con AI | RAG, búsqueda híbrida | decides con argumentos si hace falta RAG |
| 4. Agentes | loop, handoffs, gates | justificas agente vs. workflow con datos |
| 5. Harness | políticas, sandbox, presupuestos | señalas el único punto donde se decide cada acción |
| 6. Confiabilidad | checkpoints, durable execution | sabes qué pasa si el proceso muere en cada línea |
| 7. Observabilidad | trazas, tokens medidos | reconstruyes una ejecución sin repetirla |
| 8. Evals | datasets, jueces calibrados | dices si un cambio mejoró, con un intervalo |
| 9. Seguridad | injection, trifecta letal | propones controles que no dependen del modelo |
| 10. Arquitectura | el sistema completo | justificas cada caja y las que no construyes |
La habilidad transversal: desconfiar de las afirmaciones, incluidas las propias, hasta verlas cumplirse en el camino real de ejecución.
Para llevar
- Elige el nivel de arquitectura más bajo que resuelva el problema; cada nivel agrega costo operativo.
- Construye lo diferencial o lo que tus restricciones exigen; adopta el resto y declara lo que dejas fuera.
- Las garantías viven fuera del modelo: capacidades, políticas, red, secretos y presupuestos.
- Justifica cada componente con una necesidad medida, no con una tendencia.
Comprueba lo aprendido
¿Por qué docket rechaza usar un agent framework para su propio loop?
Porque el framework sería dueño del loop y, con él, de los puntos de intercepción donde docket aplica sus políticas; los controles quedarían sujetos a la API de un tercero.
¿Qué capa detiene de forma más robusta un `python3 -c` que descarga y ejecuta un script?
La red restringida. El clasificador de docket permite ese comando porque python3 está en la allowlist; si el agente solo alcanza los registries de paquetes, la descarga falla.
¿Qué garantiza el eval gate de Adapta antes de servir un adapter?
Que el adapter supere un examen sobre ejemplos que no vio en el , con un puntaje absoluto suficiente o una mejora clara sobre el ; si no, no puede respaldar un endpoint.