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 está de guardia a las 2 a.m. tratando de entender por qué un agente filtró silenciosamente los tickets de un cliente al índice de recuperación de otro tenant, y el postmortem descubre que nunca hubo un conjunto de evaluación, nunca hubo un límite de permisos y nunca hubo una manera de revertir el prompt.
Ambos desarrolladores usaron IA. Solo uno de ellos estaba construyendo un sistema de IA.
Esa distinción se está volviendo la más importante de nuestro oficio en este momento, y la mayor parte del discurso todavía la difumina.
La nueva base: programar asistido por IA
Primero quiero ser claro en algo. Programar asistido por 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 enviar código está haciendo trabajo de ingeniería real. Está:
- Aumentando su rendimiento personal de una forma que era inimaginable hace cinco años.
- Reduciendo 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.
- Siendo obligado a mejorar en descomposición, gestión de contexto y comunicación clara, porque eso es lo que hace útiles a las herramientas.
Cualquiera en un puesto de liderazgo que descarte esto va a quedar atrás frente al equipo que lo abrazó. No me interesa hacer de portero con la productividad.
Pero hay un límite en lo que este tipo de trabajo te dice sobre la profundidad de un desarrollador. Un desarrollador asistido por IA puede ser excelente operando las herramientas y aun así no saber cómo se comporta un modelo bajo entrada adversaria, 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 las suites de evaluación atrapan regresiones silenciosas, cómo se acumulan costo y latencia a través de un agente multipaso, o cómo falla un modelo cuando está confiadamente equivocado.
Nada de eso es culpa del desarrollador. Es solo que producir código es una habilidad distinta de diseñar un sistema que tiene un modelo adentro.
La otra habilidad: ingeniería de sistemas de IA
Quien construye sistemas de IA está haciendo algo categóricamente distinto. No está "usando IA": está construyendo la superficie sobre la que otras personas van a confiar para usar IA de forma segura.
Eso significa:
- Diseñar el sistema completo alrededor del modelo, no solo llamar al modelo. El modelo es un componente. El sistema son las fuentes de datos, la capa de recuperación, las herramientas 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 acarrea entre turnos.
- Tratar la calidad de datos como tema de primera clase: ingesta, deduplicación, estrategia de chunking, elección de embeddings, búsqueda híbrida léxica + vectorial, reranking, metadatos, frescura y el control de acceso que decide qué chunks puede siquiera ver un usuario.
- Construir bucles de evaluación para precisión, tasa de alucinación, comportamiento de rechazo, captura de regresiones y éxito de tarea, separando el conjunto bloqueante del de monitoreo y del backlog. (Sobre esto hemos escrito en detalle.)
- Operar el sistema: presupuestos de latencia, techos de costo, trazas a través de llamadas a modelo y herramientas, control de versiones de prompts y modelos, detección de deriva y un rollback que realmente funcione.
- Diseñar guardrails: alcances de permisos, listas blancas de herramientas, checkpoints humanos para acciones irreversibles, modos de fallo seguros cuando el modelo está incierto.
- Saber cuándo el modelo está equivocado, sobreconfiado, incompleto, inseguro, o cuándo se le está pidiendo hacer algo que no debería estar haciendo.
La lista se lee larga porque la superficie es larga. Nada es exótico y nada requiere un doctorado. Lo que sí requiere es tratar al modelo como un componente poderoso pero poco fiable alrededor del cual hay que diseñar, 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 corre localmente, lo envía. Tiempo total: una tarde. Es buen trabajo.
Escena dos. Otro desarrollador está diseñando una plataforma de análisis de código con IA que ingiere el monorepo de una empresa, lo embebe y permite a los ingenieros hacerle preguntas. Está pensando en: cómo trocear código sin romper fronteras semánticas, si embebe a nivel de función o de archivo, cómo filtrar la recuperación por los repos a los que el usuario que pregunta tiene acceso, cómo evaluar si "la respuesta citó el archivo correcto," cómo atrapar regresiones silenciosas cuando cambian de modelo de embeddings, qué pasa cuando el índice está desactualizado, cómo presupuestar el costo por consulta y cómo exponer trazas cuando alguien dice "la respuesta fue incorrecta." Tiempo total: semanas, con un equipo real. También es buen trabajo, pero es una clase completamente distinta de trabajo.
O, dicho más crudo: un desarrollador que le pide a un agente que escriba una pieza de copy de marketing está haciendo trabajo asistido por IA. Un desarrollador que construye una plataforma agéntica que corre optimización continua de campañas — proponiendo variantes, lanzando tests, condicionando lanzamientos al lift de conversión, vigilando inyección de prompt desde contenido generado por usuarios y manteniendo a un humano en el loop sobre el gasto — está construyendo un sistema de IA.
O, la que veo más seguido: un desarrollador que dice "usamos RAG" porque conectó una llamada de embeddings y un vector store, versus un desarrollador que diseña recuperación segura con chunking apropiado, búsqueda híbrida, filtros por metadatos, control de acceso por tenant, reranking y un conjunto de evaluación que prueba que el sistema responde correctamente bajo carga. El primero hace demo. El segundo sobrevive a producción.
Una curva de madurez
Es más útil pensar esto como una curva que como un binario. A grandes rasgos:
- Usuario de herramientas de IA. Usa ChatGPT o Claude en un navegador para desbloquearse.
- Power user de prompts y flujos. Tiene bibliotecas personales de prompts, usa agentes de código dentro del editor, automatiza partes de su trabajo diario.
- Constructor de funcionalidades de IA. Agrega una funcionalidad con modelo a un producto existente. Llama a una API, escribe un prompt, lo envía detrás de un flag.
- Ingeniero de sistemas de IA. Diseña el sistema completo alrededor del modelo: recuperación, evaluación, 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 de forma segura. Es dueño de las convenciones, las evals, el límite de seguridad, el modelo de costo y el camino del prototipo a producción para toda la organización.
La mayoría de los desarrolladores hoy vive entre 1 y 3. La escasez — y el verdadero diferenciador — está en 4 y 5. No porque esos niveles estén bloqueados por porteros, sino porque requieren un tipo distinto de criterio de ingeniería que la fluidez de 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 dramáticamente lo que puedes hacer, y la gente que se niegue a aprenderla se va a quedar atrás.
Construir sistemas de IA es entender el motor, los sensores, las condiciones de la carretera, los sistemas de seguridad, el calendario de mantenimiento y los modos de fallo. Es lo que te permite decidir cuándo el auto es seguro para circular en vía pública, cuándo los frenos están por irse, qué hacer cuando la carretera tiene hielo y cómo diseñar un vehículo para que otra persona lo conduzca.
Ambas cosas importan. No son la misma habilidad. Y una de ellas es la que quieres en la persona que certifica el auto para producción.
Lo que esto implica para contratar, equipos y palanca
La trampa que veo seguido es equipos que confunden las dos cosas. Contratan por fluidez en prompts y luego ponen a esa persona a cargo de un agente en producción. Premian al desarrollador que envió seis funcionalidades con IA en un trimestre sin preguntar qué pasa cuando esas funcionalidades reciben tráfico. Ponen "AI engineer" en la descripción del puesto y luego se sorprenden cuando la persona que contrataron no puede depurar una regresión de recuperación ni diseñar una suite de evals.
La salida no es devaluar a los desarrolladores fluidos en prompts. Es ser honestos sobre qué trabajo es cuál y hacer crecer a la gente deliberadamente a lo largo de la curva. Los ingenieros más fuertes con los que trabajé este año son los que combinan velocidad asistida por IA en las hojas de su trabajo — generar código, explorar APIs, esbozar componentes — con criterio de ingeniería profundo sobre el sistema alrededor. Envían más rápido y sus sistemas aguantan.
Esa es la combinación. No "usuarios de IA" versus "ingenieros de verdad." Ejecución asistida por IA acoplada a pensamiento de sistemas.
Cierre
El desarrollo basado en prompts no es falso. No es inútil. Es la nueva base, y un desarrollador que se niegue a aprenderlo está eligiendo ser más lento que el mercado.
Pero la base no es el diferenciador.
El futuro no pertenece solo a los desarrolladores que pueden programar con IA. Pertenece a los desarrolladores que entienden lo suficiente como para construir sistemas donde se pueda confiar en la IA.