Agentic Engineering: Trabajar Con AI, No Solo Usarla

El agent no siguió instrucciones. Siguió el sistema.

Una ingeniera senior en Vercel lanza una feature en tres horas. La feature requirió cambios en cuatro archivos, una migración de base de datos, un nuevo endpoint de API y actualización del manejo de estado en el client-side. Ella no escribió la mayor parte del código. Tampoco copió y pegó desde ChatGPT. Trabajó con un agent que entendía las convenciones del proyecto, tenía acceso a la suite de tests, podía leer la configuración de deploy y sabía cuándo pedir aclaraciones versus cuándo avanzar. El agent no era una herramienta que ella usó. Era un colaborador alrededor del cual ella diseñó un sistema.

Esto es agentic engineering: la disciplina de diseñar sistemas, workflows y feedback loops donde los agentes de AI operan como participantes colaborativos en el proceso de ingeniería, en lugar de generadores pasivos de código esperando prompts. En product.engineer, definimos agentic engineering como el cambio de "cómo escribo un mejor prompt" a "cómo arquitecto un entorno donde un agent puede hacer trabajo significativo y confiable a mi lado". Va más allá de "cómo escribo un mejor prompt" hacia "cómo arquitecto un entorno donde un agent puede hacer trabajo significativo y confiable junto a mí".

La distinción importa para el product engineer. Cuando eres dueño de los resultados desde la definición del problema hasta la feature deployada, necesitas agents que carguen peso real en el proceso. No autocomplete. No un chatbot que interrogas entre el trabajo de verdad. Un colaborador genuino que mantiene contexto, toma iniciativa dentro de límites y multiplica tu capacidad en lugar de solo tu velocidad de escritura.

La brecha entre la asistencia pasiva de AI (autocomplete, chat, generación con un solo prompt) y los workflows agénticos (donde la AI mantiene estado entre tareas, tiene acceso a herramientas y opera con autonomía definida) es enorme. Esa brecha no se trata de mejores modelos. Se trata de mejor diseño de sistemas.

Qué significa realmente agentic engineering

Agentic engineering no es un nuevo framework ni una librería que instalas. Es un enfoque para construir software donde tratas a los agentes de AI como participantes del sistema con roles definidos, capacidades, restricciones e interfaces de comunicación. Diseñas el sistema alrededor de la colaboración, no alrededor del prompt.

Esto significa pensar en:

• Límites del agent. ¿Qué puede hacer este agent? ¿Qué no debería hacer nunca? ¿Qué dispara una devolución al humano?
• Estado compartido. ¿Cómo accede el agent al mismo contexto que tengo yo? ¿Cómo veo lo que ha hecho?
• Feedback loops. ¿Cómo aprende el agent de las correcciones dentro de una sesión? ¿Cómo mejora el sistema entre sesiones?
• Modos de falla. Cuando el agent comete un error, ¿cómo lo detectamos temprano? ¿Cómo nos recuperamos sin perder trabajo?
• Rutas de escalación. ¿Qué decisiones requieren juicio humano? ¿Cómo señala el agent su incertidumbre?

Si has leído sobre context engineering, ya entiendes una pieza crítica: el entorno de información determina el comportamiento del agent. Agentic engineering lleva eso más lejos. Context engineering trata sobre lo que el agent sabe. Agentic engineering trata sobre lo que el agent hace, cómo participa y cómo el sistema humano-agent completo produce mejores resultados de lo que cualquiera podría lograr solo.

Piénsalo así. Un carpintero no "usa" una sierra de mesa. Tiene un taller diseñado alrededor de ella: el material fluye en una dirección específica, las protecciones de seguridad están posicionadas para la altura del carpintero, la guía está calibrada para las dimensiones del proyecto. La sierra es poderosa, pero el diseño del taller es lo que hace al carpintero productivo y seguro. Agentic engineering es diseño de taller para colaboración con AI.

El espectro: de autocomplete a colaborador

No toda interacción con AI necesita ser agéntica. Pero entender dónde se ubica tu workflow en el espectro te ayuda a identificar dónde un mejor diseño de sistema multiplicaría tu output.

La mayoría de los ingenieros están atrapados entre los niveles 2 y 3. Le piden a la AI que haga algo, revisan el output, lo pegan en su editor y repiten. Cada interacción empieza de cero. Sin contexto acumulado. Sin estado compartido. Sin efecto compuesto.

Agentic engineering comienza en el nivel 4 y diseña deliberadamente para el nivel 5. La diferencia no es la capacidad del modelo. Un prompt enviado a Claude en el nivel 2 usa el mismo modelo que Claude Code en el nivel 4. La diferencia es el sistema alrededor del modelo: contexto persistente, acceso a herramientas, conciencia del sistema de archivos, feedback iterativo y límites definidos.

El equipo de ingeniería de Stripe publicó un blog post a principios de 2026 describiendo su infraestructura interna de agents. Sus agents operan en el nivel 5 para dominios específicos: debugging de integraciones de pago, asistencia para migración de APIs y generación de documentación. Cada agent tiene un "acuerdo operativo" definido que especifica sus capacidades, restricciones, disparadores de escalación y mecanismos de feedback. El resultado, reportaron, fue un aumento de 3.2x en el throughput de los ingenieros para tareas dentro de esos dominios, comparado con un aumento de 1.4x cuando los mismos ingenieros usaban asistencia de AI basada en chat.

El multiplicador viene del sistema, no del modelo.

Cinco principios de agentic engineering

Después de trabajar con agents en producción por más de un año, entrenar ingenieros en la transición y observar tanto éxitos espectaculares como fracasos catastróficos, el framework de product.engineer para sistemas agénticos destila la disciplina en cinco principios. Estos no son teóricos. Vienen de observar equipos reales lanzando productos reales.

Principio 1: Diseña los límites antes que las capacidades

El primer instinto al integrar un agent es maximizar sus capacidades. Darle acceso a todo. Dejarlo hacer cualquier cosa. Esto está mal. Está mal de la misma forma en que darle acceso de admin a producción a un nuevo empleado el primer día está mal. No porque sea malicioso, sino porque la capacidad sin límites produce sistemas impredecibles.

Empieza con los límites. Define lo que el agent no puede hacer. Define lo que requiere confirmación. Define lo que dispara una escalación. Luego expande las capacidades dentro de esos límites.

En Linear, sus features de AI tienen listas explícitas de "nunca": nunca modificar la prioridad de un issue sin confirmación del usuario, nunca cerrar un issue autónomamente, nunca reasignar trabajo entre equipos. Estas restricciones no son limitaciones. Son arquitectura de confianza. Los usuarios confían en la AI porque conocen sus límites. Los ingenieros confían en el sistema porque pueden razonar sobre su comportamiento.

El product engineer que construye sistemas agénticos aprende a preguntar: "¿Qué es lo peor que este agent podría hacer?" antes de preguntar "¿Qué es lo mejor que este agent podría hacer?"

Principio 2: Haz que el estado sea visible y compartido

Un agent que opera en una caja negra es un riesgo. Necesitas ver lo que ve, entender por qué tomó decisiones e intervenir cuando su trayectoria diverge de tu intención.

Esto significa diseñar para observabilidad desde el día uno:

• Los agents deben registrar su razonamiento, no solo sus acciones
• Los context windows deben ser inspeccionables (¿qué "vio" el agent cuando tomó esa decisión?)
• Las llamadas a herramientas deben ser auditables
• Los resultados intermedios deben poder guardarse como checkpoints

El equipo interno de herramientas de ingeniería de Notion construyó un sistema de agents para la generación de documentación de su API. Su decisión clave de diseño: cada acción del agent produce una "traza de pensamiento" visible que los ingenieros pueden revisar, anotar y usar para corregir comportamiento futuro. Reportaron que esta visibilidad redujo los errores del agent en un 41% en tres meses, no porque el modelo mejoró sino porque los ingenieros podían detectar la deriva de trayectoria temprano y proporcionar feedback correctivo que moldeaba el comportamiento subsecuente.

Estado compartido también significa que el agent ve lo que tú ves. Cuando haces un cambio manual, el agent debería saberlo. Cuando el agent hace un cambio, tu IDE debería reflejarlo inmediatamente. La colaboración se rompe en el momento en que cualquier participante trabaja con información desactualizada.

Principio 3: Construye para corrección iterativa, no para perfección en un solo intento

La mentalidad del autocomplete espera que la AI acierte en el primer intento. Haces un prompt, obtienes output, evalúas. Si está mal, intentas un prompt diferente. Esto es agotador y no produce efecto compuesto.

Agentic engineering espera iteración. El primer output del agent es un borrador. Tu corrección no es un fracaso; es data. El sistema está diseñado para que las correcciones mejoren los outputs subsecuentes dentro de la misma sesión y, idealmente, entre sesiones.

Aquí es donde harness engineering conecta directamente. El harness (archivos CLAUDE.md, reglas de proyecto, convenciones de código, configuraciones de tests) es el mecanismo de corrección persistente. Cada vez que corriges a un agent y codificas esa corrección en el harness, estás entrenando el sistema sin entrenar el modelo. Estás acumulando conocimiento institucional que hace que la siguiente sesión de colaboración comience desde una línea base más alta.

La documentación de Claude Code de Anthropic llama a esto "memory" pero el principio de ingeniería es más antiguo: es gestión de configuración aplicada a la colaboración con AI. Tus correcciones son código. Viven en control de versiones. Son revisables, testeables y componibles.

Principio 4: Ajusta la autonomía a la confianza

No todas las tareas tienen el mismo perfil de riesgo. Un fix de typo en un README es de bajo riesgo. Una migración de esquema de base de datos es de alto riesgo. Tu sistema agéntico debería modular la autonomía del agent basándose en el nivel de confianza de la tarea.

Un framework práctico:

• Alta confianza, bajo riesgo: El agent actúa autónomamente (formateo, fixes de linting, generación de boilerplate)
• Alta confianza, alto riesgo: El agent propone, el humano aprueba (refactoring, actualización de dependencias)
• Baja confianza, bajo riesgo: El agent intenta, el humano revisa asincrónicamente (borradores de documentación, generación de tests)
• Baja confianza, alto riesgo: El agent proporciona análisis, el humano decide y actúa (cambios de arquitectura, migraciones de datos)

Esta no es una idea nueva. Es el mismo principio detrás de los pipelines de deploy: automatizados para cambios de bajo riesgo, con gates para los de alto riesgo. Agentic engineering aplica el mismo rigor a la colaboración con AI.

El equipo interno de herramientas de Shopify presentó datos en su engineering summit de 2025 mostrando que los equipos usando autonomía calibrada por confianza (agents con autonomía variable basada en el riesgo de la tarea) lanzaron 2.7x más rápido que los equipos usando agents con autonomía fija. Los equipos de autonomía fija o configuraban la autonomía demasiado alta (y pasaban tiempo arreglando errores del agent en áreas de alto riesgo) o demasiado baja (y perdían velocidad en tareas triviales que no necesitaban revisión humana).

Principio 5: Trata al agent como un colaborador junior, no como un arquitecto senior

Este es el cambio de mentalidad que separa a los ingenieros que obtienen 2x de los agents versus los que obtienen 5x. El agent no es un oráculo. No tiene gusto. No tiene contexto organizacional. No sabe qué tradeoffs tu equipo haría diferente de lo que sugieren los datos de entrenamiento.

Trátalo como un ingeniero junior talentoso: rápido, con conocimiento de sintaxis y patrones, incansable, pero sin juicio sobre qué importa, qué es riesgoso y qué necesita realmente el usuario. Tú provees el juicio. Tú provees el sentido de producto. Tú provees el "por qué". El agent provee el "cómo", rápidamente y a escala.

Esto significa que aún necesitas ser un ingeniero fuerte. Aún necesitas entender el sistema profundamente. Aún necesitas gusto. De hecho, agentic engineering requiere más juicio, no menos, porque estás revisando y dirigiendo más output por unidad de tiempo. El product engineer que trabaja con agents no es alguien que programa menos. Es alguien que piensa más y escribe menos.

El workflow de agentic engineering en la práctica

Así se ve una sesión concreta de agentic engineering para un product engineer lanzando una feature. Esto no es teórico. Refleja workflows reales que he observado y practicado.

Mañana (30 minutos): Carga de contexto y definición de dirección

El ingeniero abre su IDE con una sesión de agent. El agent ya ha cargado las convenciones del proyecto desde archivos de configuración. El ingeniero describe la feature a nivel de producto: "Necesitamos permitir que los usuarios exporten sus datos de dashboard como CSV. Lo han estado pidiendo por meses. Debería funcionar para cualquier dashboard, manejar datasets grandes sin timeout y respetar los límites de permisos".

El agent hace dos preguntas de clarificación sobre edge cases. El ingeniero responde. El agent propone un enfoque de implementación: streaming endpoint, background job para exportaciones grandes, verificación de permisos a nivel de query. El ingeniero está de acuerdo con el enfoque pero especifica que quiere que el indicador de progreso use la infraestructura existente de WebSocket en lugar de polling. Esta fase de alta especificación es donde la regla 30-30-30 de product.engineer aplica directamente a workflows agénticos: invertir 30% del tiempo en definir restricciones y límites por adelantado significa que el agent opera dentro de un envelope bien especificado para el 70% restante.

Mediodía (2 horas): Implementación colaborativa

El agent escribe la implementación inicial a través de cuatro archivos. El ingeniero revisa cada archivo conforme se produce, haciendo correcciones en tiempo real. "No crees una nueva clase de servicio aquí; extiende el ExportService existente". El agent ajusta y continúa. El ingeniero detecta un problema potencial con la verificación de permisos y explica el edge case (los dashboards compartidos tienen semánticas de permisos diferentes a los personales). El agent incorpora esto y agrega un test case para ello.

Tarde (1 hora): Testing y refinamiento

El agent genera tests de integración basados en la implementación. El ingeniero agrega tres escenarios que el agent no contempló (todos relacionados con contexto organizacional: configuraciones específicas de clientes que crean edge cases). El agent ejecuta la suite de tests, identifica dos fallas, propone fixes y el ingeniero aprueba ambos.

Tiempo total: 3.5 horas para una feature que habría tomado 1.5 a 2 días con desarrollo tradicional. La calidad es mayor porque la cobertura de tests es más exhaustiva. El juicio del ingeniero se aplicó en cada punto de decisión crítico. El agent manejó la velocidad de implementación.

Desde la experiencia de Felipe

En mi trabajo como Senior Product Engineer en AWS, he visto la transición de "AI como herramienta" a "AI como colaborador" suceder en tiempo real a través de equipos. Los ingenieros que luchan son los que intentan delegar problemas completos a los agents y luego pasan más tiempo debuggeando el output del agent de lo que habrían pasado escribiendo el código ellos mismos. Están usando AI, no trabajando con ella.

Los ingenieros que prosperan son los que invierten tiempo en diseño de sistemas: configurando las convenciones de su proyecto, calibrando los límites del agent, construyendo feedback loops que se componen entre sesiones. Habiendo entrenado a más de 12,000 ingenieros y contratado a más de 600, puedo decirles que el patrón es claro. Los mejores product engineers de hoy no son los que escriben más rápido ni los que memorizan más firmas de API. Son los que pueden arquitectar una colaboración con un sistema de AI que multiplica su juicio a través de más superficie. Eso es agentic engineering en su forma más pura.

La diferencia entre un ingeniero 2x y un ingeniero 10x en 2026 no es la habilidad de programación pura. Es el diseño de sistemas para colaboración humano-AI.

Anti-patrones comunes a evitar

Agentic engineering falla de formas predecibles. Reconocer estos anti-patrones ahorra tiempo:

La Trampa de la Delegación. Entregar al agent una tarea vaga y compleja esperando un resultado perfecto. "Constrúyeme un sistema de autenticación" no es una colaboración. Es una delegación que requerirá más tiempo para arreglar que para construir correctamente en colaboración.

La Espiral de Corrección. Pasar más tiempo corrigiendo el output del agent de lo que la tarea tomaría manualmente. Si vas en tu cuarta corrección por el mismo problema, detente. El sistema no está configurado correctamente. Arregla el límite o el contexto, no el output.

El Loop de Amnesia. Corregir el mismo error en cada sesión porque las correcciones no se persisten en el sistema. Si le dices al agent lo mismo tres veces, esa información pertenece a un archivo de configuración, no a tu memoria.

El Precipicio de Autonomía. Darle al agent autonomía completa en una tarea de alto riesgo porque manejó bien versiones más simples. La competencia en tareas fáciles no predice competencia en tareas difíciles. Ajusta la autonomía al perfil de riesgo de la tarea específica cada vez.

El Patrón de Aislamiento. Usar el agent aislado del workflow de tu equipo. Si el output del agent no pasa por code review, no corre en CI y no está sujeto a los mismos quality gates que el código escrito por humanos, tienes un workflow sombra que divergirá de los estándares del equipo.

Midiendo la efectividad de agentic engineering

No puedes mejorar lo que no mides. Aquí están las métricas que importan:

• Throughput por decisión de juicio. ¿Cuánto output produce cada decisión humana? En un sistema agéntico bien diseñado, una decisión arquitectónica del ingeniero debería cascadear en múltiples componentes correctamente implementados.
• Precisión en el primer intento. ¿Qué porcentaje del output del agent se acepta sin corrección? Rastrea esto con el tiempo. Si no mejora, tu sistema no está aprendiendo.
• Ratio de corrección-a-configuración. Cuando corriges al agent, ¿con qué frecuencia esa corrección se codifica en configuración persistente? Un ratio saludable está por encima del 50%.
• Tasa de escalación. ¿Con qué frecuencia el agent identifica correctamente tareas que necesitan juicio humano? Tanto los falsos positivos (escalaciones innecesarias que te ralentizan) como los falsos negativos (escalaciones perdidas que causan errores) importan.
• Tiempo hasta el primer commit. ¿Qué tan rápido una nueva feature va de descripción a primer commit funcional? Esto mide el loop agéntico completo, no solo la velocidad de generación de código.

PostHog rastrea estas métricas para su workflow interno de desarrollo asistido por AI. Reportaron en su blog de ingeniería que el tiempo hasta el primer commit cayó un 58% después de invertir dos semanas en diseño de sistema agéntico (principalmente configuración de harness y definición de límites). Su tasa de corrección bajó de 34% a 12% en tres meses conforme sus archivos de configuración acumularon conocimiento institucional.

El futuro son sistemas colaborativos

Agentic engineering no se trata de reemplazar ingenieros. Se trata de rediseñar el proceso de ingeniería para incluir a la AI como participante de primera clase. El product engineer de 2026 y más allá es alguien que diseña estos sistemas colaborativos tan deliberadamente como diseña su arquitectura de software.

Los agents van a mejorar. Los modelos serán más capaces, los context windows se expandirán, el uso de herramientas será más confiable. Pero mejores modelos sin mejor diseño de sistemas solo significa generación más rápida de output que aún necesita la misma cantidad de revisión humana. La ventaja viene del sistema, no del modelo.

Empieza con los límites. Haz el estado visible. Construye para iteración. Ajusta la autonomía a la confianza. Mantén tu juicio en el centro. Eso es agentic engineering. No una técnica de prompting. Una disciplina de sistemas.

Puntos clave

• Agentic engineering diseña sistemas donde los agentes de AI colaboran dentro de límites definidos, no solo responden a prompts.
• La brecha de productividad entre el uso pasivo de AI (la investigación de GitHub midió una mejora de velocidad del 55% solo a nivel de autocomplete) y los workflows agénticos viene del diseño de sistemas, no de mejores modelos.
• Ajusta la autonomía del agent al riesgo de la tarea: alta confianza y bajo riesgo obtiene autonomía completa, baja confianza y alto riesgo se mantiene liderado por humanos.
• Trata a los agentes de AI como ingenieros junior talentosos que necesitan dirección, revisión y límites claros para producir trabajo de calidad.
• Codifica cada corrección en configuración persistente para que el sistema mejore entre sesiones sin reentrenar el modelo.

FAQ

¿Cuál es la diferencia entre agentic engineering y prompt engineering?

Prompt engineering se enfoca en elaborar inputs individuales para obtener mejores outputs de un modelo. Agentic engineering es una disciplina de sistemas que diseña todo el entorno de colaboración: límites, estado compartido, feedback loops, rutas de escalación y calibración de autonomía. Prompt engineering es un componente pequeño dentro de un sistema de agentic engineering.

¿Necesito ser un ingeniero senior para practicar agentic engineering?

Necesitas suficiente juicio de ingeniería para establecer límites significativos y evaluar el output del agent. En la práctica, esto significa que necesitas fundamentos sólidos: comprensión de diseño de sistemas, testing, deploy y el dominio en el que trabajas. Un product engineer de nivel medio con fuerte pensamiento sistémico puede practicar agentic engineering efectivamente. Un ingeniero junior sin esos fundamentos tendrá dificultades para establecer límites apropiados o detectar errores del agent.

¿Qué herramientas soportan workflows de agentic engineering?

A mediados de 2026, las herramientas más alineadas con los principios de agentic engineering incluyen Claude Code (contexto persistente, acceso a herramientas, configuración de proyecto), Cursor en modo Composer (contexto multi-archivo, corrección iterativa) y frameworks de agents personalizados construidos sobre las APIs de Anthropic o OpenAI con tool use. La herramienta específica importa menos que el diseño del sistema a su alrededor. Cualquier agent con contexto persistente, acceso a herramientas y límites configurables puede soportar un workflow agéntico.

¿Cómo se relaciona agentic engineering con product engineering?

Un product engineer es dueño de los resultados desde el problema hasta producción. Agentic engineering multiplica esa responsabilidad al permitir que un ingeniero ejecute a través de más superficie sin perder juicio ni calidad. Su ventaja única en workflows agénticos es la capacidad de proveer contexto de producto, empatía con el usuario y juicio de negocio que los agents no pueden generar de forma independiente.

¿Agentic engineering es solo "usar mejor las herramientas de AI"?

No. Usar mejor las herramientas de AI es prompt engineering. Agentic engineering es diseñar sistemas donde los agentes de AI participan como colaboradores con roles definidos. La diferencia es arquitectónica: no estás optimizando inputs a una herramienta, estás diseñando un workflow colaborativo que distribuye trabajo cognitivo entre juicio humano y ejecución de máquina.

Lectura relacionada

• What Is a Product Engineer?
• Context Engineering: The Skill That Replaced Prompt Engineering
• Harness Engineering
• From Vibe Coding to Vibe Engineering
• Don't Build Agents, Build Skills