Un desarrollador entrega una funcionalidad en una tarde con Claude Code, abre un pull request y escribe «AI-powered» en la descripción. Su manager asiente. El release sale. Una semana después, otro desarrollador recibe una alerta a mitad de un deploy mientras intenta entender por qué un agente filtró en silencio los tickets de un cliente al índice de recuperación de otro tenant, y el post mortem descubre que nunca hubo eval, ni límite de permisos, ni forma de revertir el prompt.
Los dos usaron IA. Solo uno estaba construyendo un sistema de IA.
Esa distinción se está volviendo la más importante del oficio ahora mismo, y casi todo el discurso todavía la difumina.
La nueva base: programar con IA
Antes de nada, que quede claro: programar con IA no es una moda y no es «hacer trampa». Es la nueva base.
Un desarrollador que usa Claude Code, Cursor, Copilot, plantillas de prompts y automatización de flujos para generar, refactorizar, depurar y entregar código está haciendo ingeniería de verdad. Está:
- Multiplicando su rendimiento personal de una forma inimaginable hace cinco años.
- Bajando el costo de explorar APIs, lenguajes y frameworks que no conocía.
- Iterando más rápido sobre UI, formas de datos y refactors pequeños.
- Obligándose a mejorar en descomposición, gestión de contexto y comunicación clara, porque es lo que vuelve útiles a estas herramientas.
Cualquiera en un puesto de liderazgo que descarte esto va a quedar por detrás del equipo que lo adoptó. No me interesa hacer de guardián de la productividad.
Pero hay un límite en lo que este tipo de trabajo te dice sobre la profundidad de un desarrollador. Alguien puede ser excelente operando las herramientas y a la vez no saber cómo se comporta un modelo ante entrada adversarial, cómo un pipeline de datos ingiere y trocea documentos, cómo cambia el ranking de recuperación cuando un tenant pasa de mil registros a un millón, cómo una suite de evals atrapa regresiones silenciosas, cómo se acumulan costo y latencia a lo largo de un agente de varios pasos, o cómo falla un modelo cuando está convencido y equivocado.
Nada de eso es culpa suya. Simplemente, producir código es una habilidad distinta de diseñar un sistema que lleva un modelo dentro.
La otra habilidad: ingeniería de sistemas de IA
Quien construye sistemas de IA hace algo categóricamente distinto. No está «usando IA»: está construyendo la superficie sobre la que otras personas van a confiar para usar IA con seguridad.
Eso significa:
- Diseñar todo lo que rodea al modelo, no solo llamarlo. El modelo es un componente. El sistema son las fuentes de datos, la capa de recuperación, las tools que el modelo puede invocar, los puntos de aprobación humana, los caminos de respaldo, la observabilidad y la forma en que el estado se arrastra entre turnos.
- Tratar la calidad de datos como asunto de primera clase: ingesta, deduplicación, estrategia de chunking, elección de embeddings, búsqueda híbrida léxica y vectorial, reranking, metadatos, frescura y el control de acceso que decide qué fragmentos puede ver siquiera un usuario.
- Construir loops de eval para precisión, tasa de alucinación, comportamiento de rechazo, captura de regresiones y éxito de tarea, separando el set bloqueante del de monitoreo y del backlog. Sobre esto ya escribimos en detalle.
- Operar el sistema: presupuestos de latencia, techos de costo, traces a través de llamadas a modelo y a tools, versionado de prompts y modelos, detección de drift y un rollback que de verdad funcione.
- Diseñar guardrails: alcances de permisos, allowlists de tools, checkpoints humanos para acciones irreversibles y modos de fallo seguros cuando el modelo duda.
- Saber cuándo el modelo está equivocado, sobreconfiado, incompleto o inseguro, y cuándo se le está pidiendo algo que no debería estar haciendo.
La lista se lee larga porque la superficie es larga. Nada de esto es exótico ni requiere un doctorado. Lo que requiere es tratar al modelo como un componente potente y poco fiable alrededor del cual hay que diseñar, y no como una función mágica que devuelve respuestas.
Dos escenas
Escena uno. Un desarrollador le pide a Claude Code que genere una funcionalidad que resuma los tickets de soporte recientes de un cliente. Claude produce la ruta, el componente React y el prompt. El desarrollador revisa el diff, lo ejecuta en local y lo entrega. Tiempo total: una tarde. Es buen trabajo.
Escena dos. Otra desarrolladora está diseñando una plataforma de análisis de código que ingiere el monorepo de una empresa, lo indexa con embeddings y deja que los ingenieros le hagan preguntas. Está pensando en cómo trocear código sin romper fronteras semánticas, si conviene indexar a nivel de función o de archivo, cómo filtrar la recuperación por los repos a los que el usuario tiene acceso, cómo evaluar si «la respuesta citó el archivo correcto», cómo atrapar regresiones silenciosas al cambiar de modelo de embeddings, qué pasa cuando el índice está desactualizado, cómo presupuestar el costo por consulta y cómo exponer traces cuando alguien dice «esa respuesta estuvo mal». Tiempo total: semanas, con un equipo. También es buen trabajo, pero es otra clase de trabajo por completo.
Dicho más crudo: un desarrollador que le pide a un agente que escriba un texto de marketing está haciendo trabajo asistido por IA. Un desarrollador que construye una plataforma agéntica de optimización continua de campañas —que propone variantes, lanza tests, condiciona los lanzamientos al lift de conversión, vigila la inyección de prompts desde contenido generado por usuarios y mantiene a un humano en el loop sobre el gasto— está construyendo un sistema de IA.
O, la versión que más veo: alguien que dice «usamos RAG» porque conectó una llamada de embeddings y un vector store, frente a alguien que diseña recuperación segura con chunking sensato, búsqueda híbrida, filtros por metadatos, control de acceso por tenant, reranking y un eval que demuestra que el sistema responde bien bajo carga. El primero hace la demo. El segundo sobrevive a producción.
Una curva de madurez
Conviene pensarlo como una curva y no como un binario. A grandes rasgos:
- Usuario de herramientas de IA. Usa ChatGPT o Claude en el navegador para desatascarse.
- Power user de prompts y flujos. Tiene bibliotecas propias de prompts, usa agentes de código dentro del editor y automatiza partes de su día.
- Constructor de funcionalidades con IA. Añade una funcionalidad con modelo a un producto existente. Llama a una API, escribe un prompt y lo saca detrás de un flag.
- Ingeniero de sistemas de IA. Diseña el sistema completo alrededor del modelo: recuperación, eval, observabilidad, guardrails, costo, respaldo. Conoce los modos de fallo y los ha probado.
- Arquitecto de producto o plataforma de IA. Diseña la plataforma sobre la que otros equipos construyen funcionalidades con seguridad. Es dueño de las convenciones, los evals, el límite de seguridad, el modelo de costo y el camino del prototipo a producción para toda la organización.
Casi todos los desarrolladores viven hoy entre el 1 y el 3. La escasez —y el diferenciador real— está en el 4 y el 5. No porque esos niveles tengan guardianes en la puerta, sino porque exigen un tipo de criterio de ingeniería que la soltura con los prompts, por sí sola, no produce.
La analogía del auto
Usar IA para programar es como aprender a conducir un auto de alto rendimiento. Es una habilidad real, expande muchísimo lo que puedes hacer y quien se niegue a aprenderla se va a quedar atrás.
Construir sistemas de IA es entender el motor, los sensores, el estado de la carretera, los sistemas de seguridad, el plan de mantenimiento y los modos de fallo. Es lo que te permite decidir cuándo el auto puede salir a la vía pública, cuándo los frenos están a punto de irse, qué hacer si hay hielo y cómo diseñar un vehículo para que lo conduzca otra persona.
Las dos cosas importan. No son la misma habilidad. Y una de ellas es la que quieres en quien certifica el auto para producción.
Qué implica esto para contratar, para los equipos y para la palanca
La trampa que veo a menudo es confundir ambas cosas. Contratan por soltura con los prompts y luego ponen a esa persona a cargo de un agente en producción. Premian a quien entregó seis funcionalidades con IA en un trimestre sin preguntar qué pasa cuando esas funcionalidades reciben tráfico. Escriben «AI engineer» en la oferta y luego se sorprenden de que la persona contratada no sepa depurar una regresión de recuperación ni diseñar una suite de evals.
La salida no es devaluar a quien es rápido con los prompts. Es ser honestos sobre qué trabajo es cuál y hacer crecer a la gente a lo largo de la curva a propósito. Los ingenieros más fuertes con los que trabajé este año son los que combinan velocidad asistida por IA en las tareas de detalle —generar código, explorar APIs, esbozar componentes— con criterio profundo sobre el sistema que las rodea. Entregan más rápido y sus sistemas aguantan.
Esa es la combinación. No «usuarios de IA» contra «ingenieros de verdad», sino ejecución asistida por IA acoplada a pensamiento de sistemas.
El desarrollo basado en prompts es real, es valioso y es la nueva base: quien se niegue a aprenderlo está eligiendo ir más lento que el mercado. Pero la base no es el diferenciador. El futuro es de quienes entienden lo suficiente como para construir sistemas en los que se pueda confiar, no solo de quienes saben programar con IA.