Por favor, no inventemos otra ingeniería esta semana

Primera entrega de la serie Después del hype: ingeniería de software con agentes.

Cada pocas semanas aparece una nueva ingeniería: Prompt Engineering, Context Engineering, Harness Engineering, Loop Engineering, Compound Engineering, Agentic Engineering, Memory Engineering.

No creo que todas sean humo. Casi siempre hay una intuición útil detrás de cada nombre. El problema empieza cuando el vocabulario se vuelve más importante que la pregunta que estaba intentando responder.

Una etiqueta no vuelve confiable a un agente. Tampoco reemplaza una decisión de arquitectura, una especificación ambigua o una prueba que no comprueba lo que importa.

El problema que cada nombre intenta señalar

Podemos traducir buena parte de este vocabulario a problemas bastante concretos:

• Prompt engineering: cómo expresar una tarea con suficiente precisión.
• Context engineering: qué información necesita el agente para decidir bien.
• Harness engineering: qué herramientas, límites y verificaciones rodean al agente.
• Loop engineering: cómo permitirle iterar cuando una sola pasada no basta.
• Memory engineering: qué debe conservar un sistema entre tareas sin releer toda su historia.
• Compound engineering: cómo convertir un error repetido en una protección permanente.

Éstas son distinciones útiles. El riesgo es tratarlas como metodologías rivales, o como una lista de tecnología que hay que adoptar para “estar al día”.

En realidad describen partes distintas del mismo problema: cómo hacer que un componente probabilístico pueda trabajar dentro de un sistema de software que necesita ser entendible, verificable y mantenible.

El orden importa más que el nombre

Un agente puede tener un prompt excelente y fallar porque no conoce la restricción que vive en un ADR. Puede recibir todo el contexto del repositorio y tomar una mala decisión porque nadie definió un criterio de aceptación. Puede ejecutar un loop durante horas y pasar pruebas insuficientes sin acercarse al objetivo del usuario.

Por eso prefiero pensar en esta secuencia:

intención humana
      ↓
contexto relevante
      ↓
agente con herramientas y límites
      ↓
verificación ejecutable
      ↓
revisión donde hace falta criterio
      ↓
aprendizaje convertido en guardrail

No es una taxonomía para presentar en una diapositiva. Es una manera de localizar el fallo.

Si el agente no entendió la tarea, quizá el problema es el contexto o la especificación. Si modificó una parte correcta y rompió otra, quizá faltan contratos, tipos o pruebas de regresión. Si repite el mismo error, guardar una nota puede ayudar por un momento, pero una prueba, una regla de lint o una validación de esquema suelen ayudar más.

La nueva palabra no elimina la ingeniería anterior

Cuando un equipo dice que está haciendo “Agentic Engineering”, mi primera pregunta no es qué framework eligió. Es otra:

¿Qué cambió en la forma de definir, comprobar y mantener el software?

Si la respuesta es “ahora tenemos un agente que escribe más rápido”, todavía estamos hablando principalmente de generación de código. Eso puede ser valioso, pero no sustituye el resto del trabajo.

La ingeniería sigue apareciendo en los mismos lugares incómodos:

• decidir qué debe ser cierto antes de cambiar algo;
• reconocer qué información es relevante y cuál es ruido;
• separar una decisión reversible de una costosa;
• diseñar límites entre componentes;
• comprobar comportamientos, no sólo archivos modificados;
• decidir cuándo una excepción merece automatizarse y cuándo merece juicio.

Los agentes cambian la velocidad y el coste de algunas de estas actividades. También hacen más visible el coste de haberlas dejado implícitas.

No hace falta adoptar todo

Un proyecto pequeño no necesita una base vectorial, un grafo de memoria y cinco agentes especializados para añadir una página. Puede necesitar una instrucción clara, un archivo de contexto breve y un comando de verificación.

Un sistema que integra datos sensibles o varios dominios sí puede requerir políticas, contratos, permisos explícitos, pruebas de integración y revisión humana en puntos de riesgo. No porque se llame “agentic”, sino porque el sistema lo exige.

La regla práctica es menos atractiva que el hype, pero me parece más útil:

Añade mecanismos cuando resuelvan un modo de fallo observable; no porque una nueva etiqueta los haya puesto de moda.

La pregunta para el resto de la serie

No quiero decidir cuál de estas ingenierías “ganó”. Quiero entender qué combinación hace a un agente útil dentro de un flujo de desarrollo real.

La siguiente entrega parte de una distinción que suele perderse en las demos: un agente puede resolver una tarea aislada y aun así no ser capaz de sostener la coherencia de un sistema durante una secuencia larga de cambios.

Ésa es la diferencia entre producir código y hacer ingeniería de software.