Cómo leer: los escalones suben porque la IA asume más ejecución en cada fase, pero la línea discontinua muestra lo que cambia de verdad: en la fase 1 decides cada línea; en la fase 3 decides el sistema en el que trabaja el agente. Por eso la ingeniería importa más, no menos.
Mapa de la ruta
Contenido detallado
🧭 Dónde está realmente la IA en la ingeniería
Las tres fases (autocomplete, asistente, agente), lo que necesita un agente para funcionar, el nuevo papel del ingeniero y los límites reales de las herramientas.
Tres etapas de uso de la IA en el desarrollo. La fase 1 sugiere líneas mientras escribes. La fase 2 responde, explica y genera archivos cuando se lo pides. La fase 3 recibe una tarea y la ejecuta: lee el repositorio, edita archivos, ejecuta comandos y pruebas, analiza el error e intenta corregir su propia implementación.
Cada fase exige un tipo de control diferente. Aplicar los hábitos de la fase 1 a un agente de la fase 3 es el origen de la mayoría de los accidentes: revisas una línea mientras ya cambió dieciocho archivos.
Autocomplete = sugerencia · Asistente = respuesta a pedido · Agente = ejecución con herramientas · La responsabilidad humana pasa de la línea al sistema.
La lista de requisitos operativos de un agente: acceso controlado al repositorio, contexto, documentación, herramientas, entorno de ejecución, memoria, estado, permisos, reglas, pruebas, criterios de finalización, mecanismo de interrupción y registro de las acciones.
Cuando un agente "no funciona", casi siempre falta un elemento de esta lista; no es que el modelo sea débil. Es el diagnóstico más rápido que existe.
Agente = componente operativo dentro de un sistema controlado · Sin criterio de finalización, no hay conclusión · Sin registro, no hay auditoría.
El cambio en el trabajo: menos escribir cada línea y más especificar, preparar el contexto, definir límites, diseñar la verificación y evaluar el resultado.
Quien sigue midiendo la productividad por líneas escritas se vuelve invisible; quien estructura el sistema en el que trabaja la IA multiplica a todo el equipo.
Especificar > escribir · Evaluar el resultado es una habilidad central · La velocidad sin verificación es un riesgo acelerado.
El conocimiento duradero de ingeniería —arquitectura, pruebas, sistemas operativos, redes, APIs, seguridad, bases de datos e infraestructura— que se usa para evaluar lo que produjo la IA.
Sin fundamentos, no detectas problemas de concurrencia, fallas de seguridad, errores de modelado, dependencias frágiles ni el impacto en otro sistema; aun así, el código pasa las pruebas.
Cuanto más código se genera, más valiosa es la capacidad de evaluarlo · La herramienta cambia; la comprensión de los sistemas permanece.
Lo que la IA todavía suele hacer mal: solo ve el contexto que le diste, desconoce las reglas no escritas, supone cómo se comportan las integraciones que no puede observar y confunde «la prueba pasó» con «se cumplió la intención».
Saber dónde falla la herramienta es lo que define qué tareas delegas hoy y cuáles requieren aprobación humana.
Contexto ausente = suposición · Pasar la prueba ≠ estar correcto · Un límite conocido se convierte en regla, no en sorpresa.
La forma de trabajar en la que la única entrada es la frase del momento: sin especificación, sin pruebas, sin límites y sin revisión independiente.
Parece productivo durante una semana y pasa la factura al mes siguiente: duplicación semántica, inconsistencias entre módulos y cambios que nadie puede revisar.
La IA acelera la producción y también acelera los errores · La diferencia no está en el prompt, sino en el sistema que lo rodea.
📐 Spec-Driven Development
Cómo convertir una intención en una especificación estructurada que reduce la ambigüedad y que un agente puede ejecutar y verificar.
Un flujo en el que la especificación precede al código: intención → especificación estructurada → plan → implementación → pruebas → verificación.
La especificación es el único artefacto que indica qué es «correcto». Sin ella, el agente y la persona negocian la definición de terminado a mitad del camino.
Spec ≠ texto genérico · Reducir la ambigüedad es el objetivo · Toda spec termina en un criterio verificable.
La estructura estándar: problema, objetivo, alcance, fuera de alcance, entradas, salidas, contratos, condiciones de error, restricciones, criterios de aceptación, pruebas y definición de terminado.
Cada campo ausente se convierte en una decisión que el agente toma por su cuenta, normalmente la más genérica posible.
"Fuera del alcance" evita una refactorización salvaje · "Contratos" protege a quienes consumen tu API · "Definición de terminado" cierra la discusión.
El límite explícito de la tarea más la lista de condiciones observables que demuestran que se completó.
Un agente sin límites «mejora» lo que no se pidió; un criterio vago devuelve un trabajo que parece terminado, pero no lo está.
El criterio de aceptación se puede verificar, no es opinable · El alcance negativo vale tanto como el positivo.
La parte de la spec que fija los formatos, las interfaces y los comportamientos que se preservan, además de lo que debe ocurrir ante cada fallo.
Casi toda regresión grave en producción nace de un contrato implícito que nadie escribió y que la IA no podía adivinar.
La condición de error es un requisito · La compatibilidad es un contrato · El camino de error necesita una spec tanto como el camino feliz.
El par canónico: una solicitud de una línea frente a la versión que define medios de pago, idempotencia, estados, webhooks, reintentos, logs, compatibilidad, datos sensibles, pruebas, rollback y bloqueo de merge.
Es el ejercicio más rápido para calibrar al equipo: todos ven enseguida cuántas decisiones estaban ocultas en esa frase breve.
La ambigüedad no desaparece; alguien toma una decisión · Cuanto mejor sea la spec, menor será la posibilidad de una decisión incompatible con el sistema.
La práctica de traducir cada criterio de aceptación en una prueba automática, cerrando el ciclo spec → prueba → implementación → verificación.
Una regla escrita en texto es útil; esa misma regla como prueba es confiable, y es lo que permite delegar la ejecución al agente sin perder el control.
La prueba es la especificación ejecutable · Sin pruebas, «listo» es una opinión · El verificador es quien autoriza la autonomía.