luismori.

Modern Agent Engineering

AI Engineering AI Agents

Cómo la IA ayuda a los ingenieros a evolucionar y escalar aplicaciones modernas

La IA puede ayudar a los equipos a avanzar más rápido, pero la verdadera clave está en diseñar agentes, skills, evals, traces y ciclos de autocorrección alrededor de la aplicación.

18 min de lectura

TL;DR

La IA ayuda a los ingenieros a escalar aplicaciones modernas cuando se trata como parte del sistema de ingeniería, no como un generador mágico de código. El patrón más útil es darles a los agentes de IA objetivos claros, skills reutilizables, herramientas seguras, buena observabilidad, datasets de evaluación y ciclos de revisión humana. Luego, usar los fallos reales de producción para mejorar los prompts, el código, las herramientas, las políticas y las pruebas con el tiempo.

El cambio práctico es este: en lugar de preguntar «¿Puede la IA escribir esta funcionalidad?», pregunta «¿Puede nuestro equipo diseñar un sistema en el que la IA pueda proponer, probar, observar, corregir y escalar el trabajo de forma segura?».

Qué aprenderás aquí

  • Cómo cambia la IA el trabajo de ingeniería más allá del autocompletado.
  • Qué son los agentes y cuándo vale la pena crearlos.
  • Qué significan las «skills» en un sistema de ingeniería con IA.
  • Cómo pueden los ingenieros y PMs usar IA para evolucionar aplicaciones modernas sin perder calidad.
  • Cómo implementar un ciclo de autocorrección con traces, evals, revisión y pruebas de regresión.
  • Dónde sigue siendo necesario contar con buen criterio de producto, criterio de ingeniería y supervisión humana.

El verdadero cambio de la IA no es solo la velocidad

Las herramientas de programación con IA ya son de uso común. La investigación DORA de Google de 2025 informó que la adopción de IA entre los profesionales del desarrollo de software alcanzó el 90%, y que el 65% dependía considerablemente de la IA para su trabajo de desarrollo. Más del 80% de los encuestados dijo que la IA mejoró su productividad, y el 59% reportó un efecto positivo en la calidad del código.

Esto parece ser solo una historia de aceleración, pero hay una interpretación más sutil y útil.

La IA amplifica el sistema que la rodea.

Si un equipo tiene objetivos de producto claros, buena arquitectura, documentación clara, pruebas confiables y ciclos de revisión rápidos, la IA puede ayudarlo a avanzar más rápido. Si el equipo tiene requisitos vagos, responsabilidades sin asignar, infraestructura frágil y ningún ciclo de retroalimentación, la IA suele hacer más evidentes esas debilidades.

Por eso, la ingeniería moderna con IA se trata menos de «escribir mejores prompts» y más de mejorar el entorno en el que trabaja la IA:

  • Especificaciones y criterios de aceptación claros.
  • Tareas pequeñas con condiciones de éxito verificables.
  • Herramientas que exponen el estado real de la aplicación.
  • Evals que detectan regresiones.
  • Traces que muestran lo que el agente realmente hizo.
  • Revisión humana en puntos de control importantes.

Para los ingenieros, eso significa que el trabajo evoluciona de escribir cada línea manualmente a diseñar un sistema de entrega en el que se pueda confiar. Para los PMs, significa que la definición del producto se vuelve más importante, no menos. Cuando implementar cuesta menos, elegir el problema correcto adquiere más valor.

Dónde ayuda la IA a los ingenieros a escalar aplicaciones modernas

La IA es útil en todo el ciclo de vida de una aplicación, pero los distintos casos de uso necesitan diferentes niveles de control.

1. Descubrimiento y planificación de producto

La IA puede ayudar a resumir entrevistas con clientes, identificar sus principales problemas, comparar competidores, crear primeras versiones de especificaciones y generar listas de verificación de casos límite. Esto es especialmente útil cuando los PMs y los ingenieros intentan convertir un contexto desordenado en un plan de desarrollo claro.

Una buena planificación asistida por IA no reemplaza el criterio de producto. Le da al equipo más material para analizar.

Ejemplos de prompts que suelen funcionar bien:

Read this feature brief and produce:
1. The user problem.
2. The riskiest assumptions.
3. Missing requirements.
4. Testable acceptance criteria.
5. Questions for engineering and design.

2. Arquitectura y diseño técnico

La IA puede comparar opciones de arquitectura, generar diagramas de secuencia, identificar modos de fallo y poner a prueba las decisiones. Es útil como segundo revisor cuando le pides que argumente en contra de tu diseño.

La clave es darle al modelo restricciones reales: código existente, patrones de tráfico, objetivos de latencia, habilidades del equipo, requisitos de cumplimiento y límites operativos.

3. Implementación

Este es el caso de uso conocido: generar código, refactorizarlo, escribir pruebas, crear la estructura inicial de APIs, migrar módulos y explicar partes desconocidas de un repositorio.

Pero los mejores equipos evitan la trampa del «prompt grande y vago, diff gigantesco». Usan la IA en ciclos pequeños:

Goal -> Small plan -> Edit -> Run tests -> Review diff -> Improve -> Merge

Los ciclos pequeños mantienen a las personas en control y facilitan la detección de defectos.

4. QA, seguridad y confiabilidad

La IA puede generar casos de prueba, inspeccionar logs, explicar fallos de CI, crear modelos de amenazas y revisar pull requests en busca de tipos específicos de bugs. Es especialmente útil cuando está conectada a herramientas: ejecutores de pruebas, linters, análisis estático, plataformas de observabilidad, sistemas de seguimiento de incidencias y logs de despliegue.

Aquí es donde los agentes se vuelven interesantes. Un agente de QA que puede abrir la aplicación, reproducir un bug, inspeccionar llamadas de red, proponer una corrección y volver a ejecutar las pruebas hace más que conversar. Está ejecutando un workflow.

5. Operaciones y mejora continua

Las aplicaciones modernas nunca están «terminadas». La IA puede ayudar a clasificar incidentes, agrupar tickets de soporte, encontrar modos de fallo recurrentes, actualizar runbooks y convertir fallos de producción en pruebas de regresión.

Este es el puente hacia los sistemas de autocorrección: cada problema de producción se convierte en aprendizaje estructurado para la aplicación y sus agentes.

¿Qué es un agente?

Un chatbot responde. Un agente trabaja.

Más concretamente, un agente es un sistema que usa un modelo para perseguir un objetivo, elegir herramientas, observar resultados y continuar hasta alcanzar una condición de finalización.

User goal
   |
   v
+---------+
| Agent   |
+---------+
   |
   +--> plan next step
   +--> call tool
   +--> observe result
   +--> decide whether to continue
   |
   v
Final answer, code change, ticket, report, or escalation

Un agente de una aplicación suele tener cinco partes:

  • Modelo: El motor de razonamiento.
  • Instrucciones: Las reglas, la personalidad, las restricciones y el workflow.
  • Herramientas: APIs, bases de datos, acciones en el navegador, ejecutores de pruebas, búsqueda, acceso a archivos y servicios internos.
  • Memoria o contexto: Estado del usuario, decisiones anteriores, documentación, traces y archivos relevantes.
  • Guardrails: Permisos, validación, verificaciones de políticas, límites de tasa y aprobación humana.

La guía de OpenAI sobre agentes presenta el modelo, las herramientas y las instrucciones como los componentes principales. La guía de Anthropic añade una distinción arquitectónica importante: a veces necesitas un workflow con pasos fijos y, otras veces, un agente más autónomo que pueda decidir su propio camino.

Esa distinción importa.

Si la tarea es predecible, usa un workflow. Si es ambigua, requiere muchas herramientas y exige criterio en un contexto cambiante, considera usar un agente.

Workflows vs. agentes

No toda funcionalidad de IA debería ser un agente autónomo.

Usa un workflow cuando el proceso es conocido:

Input -> classify -> retrieve data -> generate draft -> validate -> send to review

Usa un agente cuando el proceso necesita decisiones dinámicas:

Goal -> inspect context -> choose tool -> observe -> choose next action -> stop or escalate

Por ejemplo:

  • Un asistente para restablecer contraseñas suele ser un workflow.
  • Un asistente para investigar casos de soporte que revisa pedidos, políticas, logs y tickets anteriores podría necesitar un agente.
  • Una tarea de migración de código que abarca muchos archivos podría necesitar un agente.
  • Un generador de textos de marketing probablemente no necesite un agente, a menos que también investigue, pruebe, publique y supervise los resultados.

El criterio de ingeniería debe ser conservador: comienza con el workflow confiable más sencillo y luego introduce más autonomía solo donde el workflow se vuelva demasiado rígido.

¿Qué son las skills?

Las skills son conocimiento reutilizable sobre tareas para sistemas de IA.

Una skill puede ser una instrucción breve, una lista de verificación, un script, un wrapper de herramienta, una política, una plantilla de prompt o un workflow completo. La idea es convertir los conocimientos prácticos que las personas aplican repetidamente en algo que el agente pueda reutilizar de forma confiable.

Piensa en las skills como «documentos de onboarding para agentes».

Ejemplos:

  • «Cómo ejecutar este repositorio localmente».
  • «Cómo escribir un endpoint de API con nuestro estilo».
  • «Cómo depurar pagos fallidos».
  • «Cómo crear una migración de base de datos segura».
  • «Cómo revisar código generado por IA».
  • «Cómo convertir un trace de producción en un eval».

Las skills ayudan porque reducen la ambigüedad. En lugar de pedirle al modelo que redescubra las convenciones de tu equipo cada vez, le proporcionas conocimiento operativo estable.

+-------------------+
| Team Knowledge    |
+-------------------+
          |
          v
+-------------------+       +------------------+
| Skill Documents   | ----> | Agent Execution  |
+-------------------+       +------------------+
          |                         |
          v                         v
  prompts, scripts,          better plans,
  checklists, tools          fewer mistakes

Una skill útil es:

  • Lo suficientemente pequeña para aplicarse a una tarea clara.
  • Específica de tu aplicación, equipo o workflow.
  • Escrita con pasos y condiciones de éxito.
  • Conectada a herramientas o comandos cuando es posible.
  • Actualizada cuando la realidad de producción te enseña algo nuevo.

Un patrón sencillo de agente para aplicaciones modernas

Aquí tienes un esquema mínimo al estilo de TypeScript. La idea importante no es el SDK exacto, sino el ciclo: decidir, actuar, observar, validar y detenerse.

type ToolResult = {
  ok: boolean;
  data?: unknown;
  error?: string;
};

type AppTool = {
  name: string;
  description: string;
  run: (input: unknown) => Promise<ToolResult>;
};

const tools: Record<string, AppTool> = {
  searchDocs: {
    name: "searchDocs",
    description: "Find relevant internal documentation.",
    run: async (input) => searchDocs(String(input)),
  },
  runTests: {
    name: "runTests",
    description: "Run the focused test suite for the current change.",
    run: async () => runCommand("npm test -- --runInBand"),
  },
};

async function runEngineeringAgent(goal: string) {
  const trace = [];
  let state = { goal, done: false, attempts: 0 };

  while (!state.done && state.attempts < 6) {
    const decision = await modelDecideNextStep({
      goal: state.goal,
      availableTools: Object.values(tools).map(({ name, description }) => ({
        name,
        description,
      })),
      trace,
    });

    const tool = tools[decision.toolName];
    if (!tool) {
      return escalateToHuman("Unknown tool requested", trace);
    }

    const result = await tool.run(decision.input);
    trace.push({ decision, result, at: new Date().toISOString() });

    if (!result.ok) {
      state.attempts += 1;
      continue;
    }

    const validation = await validateProgress(goal, trace);
    state.done = validation.done;
    state.attempts += 1;
  }

  if (!state.done) {
    return escalateToHuman("Agent reached max attempts", trace);
  }

  return {
    status: "ready_for_review",
    trace,
  };
}

Presta atención a las partes poco llamativas pero importantes:

  • El agente tiene un número máximo de intentos.
  • Cada paso se registra en un trace.
  • Las herramientas desconocidas se bloquean.
  • El progreso se valida.
  • El estado final es «listo para revisión», no «publicado mágicamente».

Ese es el enfoque que mantiene útiles a los sistemas con agentes.

El ciclo de autocorrección

La autocorrección no significa que la aplicación se reescriba silenciosamente en producción. Esa es una fantasía peligrosa.

En un sistema de ingeniería maduro, la autocorrección significa que el producto genera evidencia, el equipo convierte esa evidencia en pruebas y mejoras, y los agentes ayudan a realizar el trabajo dentro de los guardrails.

Production use
     |
     v
Traces, logs, feedback, failures
     |
     v
Human and automated review
     |
     v
Failure patterns
     |
     v
New evals and regression tests
     |
     v
Prompt, tool, policy, or code changes
     |
     v
CI gate and human review
     |
     v
Deploy
     |
     v
Observe again

Así es como mejora una aplicación que usa IA sin fingir que el modelo siempre tiene razón.

Paso 1: Capturar traces

En el software convencional, los logs te dicen qué pasó. En los agentes, los traces te dicen cómo llegó el agente a ese resultado.

Un trace debería capturar:

  • La entrada del usuario o el objetivo de la tarea.
  • El contexto recuperado.
  • Las llamadas a herramientas y sus resultados.
  • Las decisiones intermedias.
  • El resultado final.
  • La latencia, el costo y los errores.
  • La retroalimentación humana o las etiquetas de revisión.

La guía de LangChain de 2026 lo explica claramente: el código te dice qué puede hacer un agente; los traces te dicen qué hizo realmente en una ejecución específica.

Paso 2: Agregar evaluaciones

Los evals son pruebas del comportamiento de la IA. Pueden ser verificaciones deterministas, etiquetas asignadas por personas, rúbricas donde un LLM actúa como juez, datasets de referencia o pruebas completas de escenarios.

Usa evals para responder preguntas como estas:

  • ¿La respuesta cumplió con la política?
  • ¿El agente llamó a la herramienta correcta?
  • ¿Evitó acciones inseguras?
  • ¿Resolvió el problema real del usuario?
  • ¿Conservó los datos requeridos?
  • ¿Produjo código que pasa las pruebas?

La guía de OpenAI sobre evals describe las evaluaciones como el proceso de validar y probar los resultados de aplicaciones con LLM. La versión práctica para ingeniería es simple: si no puedes medir si un cambio mejoró al agente, estás adivinando.

Paso 3: Convertir fallos en datasets

Cada fallo recurrente debería convertirse en un caso de prueba reutilizable.

Bad production run
     |
     v
Reviewer labels root cause
     |
     v
Create test input + expected behavior
     |
     v
Add to offline eval suite
     |
     v
Run before future releases

Aquí es donde los PMs y los expertos de dominio aportan muchísimo valor. Pueden etiquetar si el agente resolvió la necesidad real del usuario, no solo si la respuesta parecía buena.

Paso 4: Elegir la corrección adecuada

No todo fallo de IA es un problema del prompt.

Usa este mapa:

Failure type                 Likely fix
--------------------------   --------------------------------
Missing product context      Improve retrieval or documentation
Wrong tool selected          Improve tool descriptions or routing
Unsafe action attempted      Add permissions or human approval
Bad final answer             Add evals, examples, or clearer rubric
Repeated edge-case miss      Add a skill or workflow branch
Code regression              Add tests and tighten review gates
High cost or latency         Route simpler tasks to cheaper models

La solución podría ser actualizar un prompt, pero también podría ser una herramienta mejor, un workflow más pequeño, un límite de permisos más estricto o una decisión de producto.

Paso 5: Mantener la revisión humana donde importa

La revisión humana no es un fallo de la automatización. Es parte del diseño del sistema.

Exige aprobación para:

  • Escribir en sistemas de producción.
  • Enviar mensajes externos.
  • Gestionar dinero, identidad, privacidad o seguridad.
  • Cambiar controles de acceso.
  • Publicar contenido visible para los usuarios.
  • Desplegar código.

Con el tiempo, puedes reducir la revisión de acciones de bajo riesgo y alta confianza. Pero esa autonomía debe ganarse con evidencia.

Un backlog práctico de autocorrección

Si estás diseñando una aplicación nueva hoy, agrega este backlog desde el primer día:

  • Almacenamiento de traces: Conserva registros estructurados de las ejecuciones de los agentes.
  • Captura de feedback: Permite que los usuarios y revisores etiqueten los resultados deficientes.
  • Dataset de evals: Guarda ejemplos reales con el comportamiento esperado.
  • Control de regresiones: Ejecuta evals en CI antes de publicar cambios en prompts, modelos o workflows.
  • Permisos de herramientas: Separa las herramientas de lectura de las de escritura.
  • Reglas de escalamiento: Define cuándo el agente debe detenerse y consultar a una persona.
  • Registro de skills: Guarda instrucciones de workflow reutilizables cerca del código.
  • Notas de versión para agentes: Registra los cambios en prompts, modelos, herramientas y políticas como si fueran cambios de código.

Esto facilita la mejora de la aplicación porque el sistema recuerda lo que aprendió.

Cómo deberían trabajar juntos los ingenieros y los PMs

La ingeniería asistida por IA funciona mejor cuando los PMs y los ingenieros comparten la responsabilidad por la calidad.

Los PMs pueden ayudar a definir:

  • Los objetivos de los usuarios.
  • Los resultados aceptables.
  • Los casos límite.
  • Las reglas de negocio.
  • Los momentos para escalar un caso.
  • Qué significa «bueno» en una rúbrica de eval.

Los ingenieros pueden ayudar a definir:

  • Los límites del sistema.
  • Los contratos de las herramientas.
  • La observabilidad.
  • La estrategia de pruebas.
  • La seguridad y los permisos.
  • Los controles de CI y despliegue.

Juntos, crean un mejor sistema operativo para la IA.

PM judgment                Engineering judgment
-----------                --------------------
What matters?              How should it work?
What is risky?             How can it fail?
What is good enough?       How do we verify it?
When should a human step in? What should be automated?

Dónde se equivocan los equipos con la IA

Los errores comunes son predecibles:

  • Tratar el resultado de la IA como trabajo terminado.
  • Pedir cambios enormes sin verificaciones intermedias.
  • Medir solo la velocidad, no la calidad ni el retrabajo.
  • Crear sistemas multiagente antes de que un workflow con un solo agente sea confiable.
  • Darles a los agentes demasiadas herramientas con funciones superpuestas.
  • Omitir los traces porque «tenemos logs».
  • Publicar cambios en prompts sin evals de regresión.
  • Ignorar el feedback de los PMs y expertos de dominio.

El estudio de METR de 2025 es una advertencia útil. En un ensayo controlado aleatorizado con desarrolladores experimentados de código abierto, las herramientas de IA hicieron que los participantes tardaran más en tareas realistas, aunque ellos creían que la IA los había ayudado a avanzar más rápido. Eso no significa que la IA sea inútil. Significa que la productividad depende del contexto y que la percepción de velocidad declarada por los propios participantes no es suficiente.

Un buen plan para la primera implementación

Si tuviera que agregar IA a una aplicación moderna desde cero, empezaría aquí:

  1. Elegir un workflow problemático con valor de negocio claro.
  2. Escribir el workflow humano como una serie de pasos.
  3. Agregar un asistente de IA para la parte útil más acotada.
  4. Darle primero herramientas de solo lectura.
  5. Capturar traces de cada ejecución.
  6. Revisar manualmente las primeras 50 a 100 ejecuciones reales.
  7. Convertir los fallos comunes en evals.
  8. Agregar acciones de escritura solo con aprobación previa.
  9. Medir velocidad, calidad, satisfacción del usuario, retrabajo y tasa de incidentes.
  10. Ampliar la autonomía solo cuando el conjunto de evals y los datos de los traces lo respalden.

El objetivo no es crear una demo futurista. Es crear un sistema que aprenda.

Vacíos y secciones para agregar más adelante

Este artículo se mantiene deliberadamente neutral respecto a los frameworks. Una continuación más completa podría profundizar en las decisiones de implementación:

  • Una implementación concreta con OpenAI Agents SDK o Vercel AI SDK.
  • Una configuración de tracing con LangSmith, LangWatch o una solución personalizada.
  • Un dataset de ejemplo para evals de agentes de soporte, revisión de código o QA.
  • Un modelo de seguridad para permisos de lectura y escritura de herramientas.
  • Una rúbrica accesible para PMs que permita evaluar la calidad de un producto con IA.
  • Un pipeline de CI real que bloquee las regresiones de los agentes antes del deploy.

El mayor vacío pendiente es la medición. Los equipos todavía necesitan mejores formas de conectar el uso de IA con resultados duraderos para el producto: menos retrabajo, menos incidentes, aprendizaje más rápido, mejor retención y mayor satisfacción del cliente. Las líneas de código y la cantidad de prompts no son suficientes.

Reflexión final

La IA ayuda a los ingenieros a escalar aplicaciones modernas cuando diseñamos el sistema alrededor de ella.

Los agentes necesitan herramientas. Las herramientas necesitan permisos. Los permisos necesitan guardrails. Los guardrails necesitan traces. Los traces necesitan evals. Los evals necesitan criterio humano. El criterio humano necesita contexto de producto.

Ese es el ciclo moderno.

Los equipos que lo dominen no solo entregarán más rápido. Aprenderán más rápido.

Fuentes