Patrones de ingeniería agéntica

• Una guía que organiza las formas de desarrollo en la era de los agentes de programación como Claude Code y Codex, y presenta nuevos patrones de ingeniería para colaborar con agentes
• Explica, mediante distintos patrones, cómo deberían cambiar los hábitos de desarrollo y los flujos de trabajo en un entorno donde el costo de escribir código se ha reducido drásticamente
• Organiza de forma estructurada las áreas clave del desarrollo centrado en agentes, como principios, pruebas, comprensión de código y diseño de prompts
• Cada patrón adopta la forma de un documento de patrones orientado a la práctica, con ejemplos reales de código, formas de trabajo y casos de uso de prompts
• Un recurso práctico de referencia para que los desarrolladores de la era de los agentes de programación diseñen de forma sistemática un entorno de programación basado en agentes y mantengan la calidad

---

Resumen de Agentic Engineering Patterns

• Una guía que reúne métodos de ingeniería eficaces para desarrollar junto con agentes de programación (Claude Code, OpenAI Codex, etc.)
• Ver también: artículo de presentación de Writing about Agentic Engineering Patterns
  • Un documento estructurado para añadir continuamente múltiples patrones (capítulos), al estilo de los “Design Patterns” tradicionales
  • Se centra en los cambios en el flujo de trabajo y la toma de decisiones del desarrollador en un entorno donde el costo de escribir código ha bajado mucho
  • Se publica como contenido en formato de guía actualizable, no como entrada de blog, y está previsto que siga expandiéndose

1. Principios

• Writing code is cheap now

  • Con la aparición de los agentes de programación con IA, el costo inicial de escribir código se ha reducido casi a cero
  • Antes, como escribir código era costoso, el desarrollo se apoyaba más en diseño y planificación; ahora es posible probar ideas directamente en código
  • Aunque el costo de generar código bajó, el buen código (pruebas, mantenibilidad, etc.) sigue teniendo un costo

• Hoard things you know how to do

  • Un activo importante del desarrollador es la acumulación de conocimiento sobre “qué cosas son posibles”
  • Se enfatiza el hábito de guardar y acumular distintos casos de resolución de problemas y pequeños experimentos de código en una forma reutilizable
  • El código y los ejemplos reunidos así pueden servir como insumos muy potentes al pedirle a un agente de programación que cree nuevas funciones

• Anti-patterns: things to avoid

  • Incluso si el código fue generado por un agente, compartirlo o enviar un PR sin revisión es un antipatrón que debe evitarse
  • Las descripciones de PR escritas por el agente también deben ser verificadas y corregidas por una persona
  • Para no desperdiciar el tiempo de quienes revisan el código, hay que proporcionar también pruebas, procesos de verificación y los motivos detrás de las decisiones de implementación

2. Testing y QA

• Red/green TDD

  • El desarrollo guiado por pruebas (TDD) es un patrón especialmente eficaz cuando se usa junto con agentes de programación
  • Si se escriben primero las pruebas, el agente puede generar código orientado a cumplirlas
  • Incluso con prompts mínimos, ayuda a generar código preciso y confiable

• First run the tests

  • Al trabajar con agentes de programación, las pruebas automatizadas no son opcionales, sino un elemento esencial
  • En un entorno donde el costo de escribir pruebas ha disminuido, el agente puede generarlas y corregirlas rápidamente
  • Como no se puede garantizar que el código funcione hasta que realmente se ejecute, las pruebas son fundamentales

3. Comprender el código

• Linear walkthroughs

  • Un patrón para leer y entender en orden, de principio a fin, el código o proyecto creado por el agente
  • Incluso en proyectos simples, es posible aprender nuevas tecnologías y estructuras siguiendo el flujo del código
  • Frente a la preocupación de que la generación de código con IA ralentice el aprendizaje, explorar el código en sí puede convertirse en una oportunidad de aprendizaje

• Interactive explanations

  • Una forma de entender código o sistemas conversando con el agente y pidiéndole explicaciones
  • Al repetir preguntas, se puede entender de forma gradual cómo funciona y cómo está estructurado el código
  • Un patrón que extiende el proceso de comprensión del código hacia un aprendizaje conversacional

4. Prompts anotados

• GIF optimization tool using WebAssembly and Gifsicle

  • Incluye un ejemplo de prompt para crear una herramienta de optimización de GIF basada en WebAssembly y Gifsicle
  • Presenta una forma de implementar una herramienta de una sola página con HTML, JavaScript y CSS
  • Explica cómo aprovechar agentes de programación mediante prompts y ejemplos de código reales

5. Apéndice

• Prompts I use

  • Una recopilación de ejemplos de prompts para agentes de programación que usa en la práctica
  • Organiza patrones de prompts aplicables a distintas tareas reales
  • Ofrece plantillas prácticas que pueden usarse al colaborar con agentes

[GN⁺]

Opiniones en Hacker News

• Parece que una vez más vamos a repetir lo mismo
  Vamos a tomar conceptos simples y razonables —por ejemplo, "escribe primero las pruebas", "haz módulos pequeños y componibles"—, empaquetarlos con nombres complejos y montar con eso toda una industria de consultoría
  Pero esta vez el objeto son “máquinas que hablan”. Se supone que estamos en un mundo donde solo hay que pedir las cosas con palabras

  • COBOL prometía algo parecido. Decían que, al ser un lenguaje fácil de leer para humanos, ya no harían falta programadores, pero al final, para descomponer y resolver problemas, una persona igual tenía que pensar como programador. O sea, que un lenguaje sea amigable para humanos no hace desaparecer a los programadores
  • Esta vez también parece que se repetirá el ciclo del boom de la IA. Ahora, si criticas, te responden que “no entiendes”, pero pronto van a empezar a aparecer los problemas. En especial, llegará una situación donde “la IA genera tanto código que ni humanos ni IAs pueden hacerse cargo”. Para entonces volverán a aparecer los patrones y anti-patrones, junto con consultores que prometen resolverlos
  • Como la IA habla y entiende inglés, la claridad de la interfaz se reduce. Es poderosa como una CLI, pero no queda claro qué formas funcionan mejor. Por eso es importante documentar y compartir “qué pedir y cómo pedirlo para obtener buenos resultados”. Eso sí, hay que evitar que termine degenerando otra vez en algo como la industria del coaching de OOP
  • Sí, así va a pasar otra vez, y esta vez mucho más rápido. El ciclo de 10 años de blogueros → conferencistas → libros → consultores → organismos de certificación va a aparecer comprimido en solo unos pocos años
  • No estoy de acuerdo con la crítica de que el título del artículo sea complicado. El problema más bien es el malentendido de que “solo hay que pedirlo en lenguaje natural”. En la práctica, los resultados varían muchísimo entre personas. Al final, la lección que está saliendo es que "los buenos hábitos de desarrollo para humanos también son buenos para la IA". La IA se parece a un humano, pero no es un humano. Por eso necesita más explicaciones

• Quisiera preguntarle a Simon: “¿Cómo se hace code review en un mundo donde el código es barato?”
  Los miembros del equipo abordan las cosas con la idea de “si funciona, ya está”, sin entender la estructura. Las revisiones son cada vez más grandes y yo me convierto en el cuello de botella. También he pensado en usar un revisor de IA como delegado, pero no me gusta perder ese criterio humano

  • Es un tema realmente interesante. Si la velocidad de generación de código aumenta, la revisión se vuelve el cuello de botella. Si el código es barato, tal vez se podrían bajar los estándares de revisión, pero yo más bien quiero mejor calidad. En especial, la revisión de seguridad nunca se puede omitir. Quizás haga falta un enfoque más sistemático, como el de los equipos de seguridad en organizaciones grandes
  • Si vas a usar revisión basada en agentes, la configuración del contexto es clave. Si haces un loop de planificación → ejecución → prueba/corrección → revisión/refactorización → generación de guía de QA, evolucionan no solo el código, sino también la documentación y las guías de prueba
  • “Si funciona, ya está” no es un problema técnico, sino un problema de cultura organizacional. Todavía hay empresas que valoran el código fácil de leer. Eso incluso puede convertirse en una ventaja competitiva
  • Yo invierto en automatización de análisis estático y dinámico. Uso activamente herramientas de calidad como reglas de lint personalizadas, verificación estricta de tipos y mutation testing. Como la revisión sola es lenta e ineficiente, la clave es la automatización del feedback temprano
  • Esa actitud no cambia fácilmente. Tal vez sea mejor pasarte a un equipo que sí valore la calidad del software

• Yo uso la IA sobre todo para código boilerplate o para destrabar problemas de documentación
  También he probado trabajo de tipo agente, pero todavía cuesta confiar en los resultados. Aun así, hay personas que dicen que “ya casi no escriben código”. Esa brecha me parece interesante

  • Para mí, muchas veces programar directamente es más rápido que usar IA. El proceso de planear, ejecutar y verificar termina siendo más lento. Pero en refactorizaciones grandes la IA es muchísimo más rápida
  • En los últimos meses, el rendimiento de los agentes ha subido muchísimo. Ya no se trata solo de autocompletado simple, sino de poder implementar funcionalidades completas
  • Tal vez pueda explicarse por la diferencia entre desarrolladores que sienten una especie de “rechazo raro (eww)” al código hecho por IA y los que no
  • Al final, depende del tipo de trabajo: hay casos donde la IA encaja muy bien y otros donde claramente no
  • A mí tampoco me convence el primer resultado, pero si repites varias veces el loop de revisión, la calidad sube de verdad. Si pones a una IA a revisar a otra o dejas claros los criterios de prueba, mejora muchísimo

• Últimamente estoy experimentando con un loop de programación tipo agente
  Por ejemplo, en el proyecto fesh me propuse “comprimir más un binario de Linux”. Como era un problema con pruebas claras, encajaba bien con un loop de IA
  Lo aprendido fue esto:

  • El test harness lo es todo. Sin un loop de validación, se pierde el rumbo
  • Es importante dejar que la IA pruebe cosas de forma experimental
  • Hay que dejar un scratchpad .md entre sesiones para que el aprendizaje continúe
  • Las pruebas son de verdad importantes. La IA falla de formas rarísimas, así que hay que aprovechar mucho la generación automática de pruebas
  • Sin pruebas no se puede confiar en el resultado del loop. Hace falta un proceso de validación determinista
  • Me resultó útil registrar por separado el log de decisiones y el log de rechazos. En especial, rejections.md tenía más valor. Hay que dejar constancia de “por qué se descartó este enfoque” para que la IA no repita el mismo error
  • En automatización de navegador pasa algo similar. Además de la validación funcional, hay que agregar validación de comportamiento (¿parece humano?) para que realmente sirva. Y los logs en .md mejoran muchísimo la calidad de la siguiente sesión

• Me gustaría que en la sección de pruebas se tratara el problema de las “pruebas autocumplidas” que generan los LLM
  A veces las pruebas en realidad no validan nada, o incluso pasan gracias a valores hardcodeados. Los humanos tienen que guiar a la IA hacia hábitos de prueba estrictos

  • Me gustaría ver ejemplos concretos. Parece que no hablas de un error lógico simple, sino de pruebas que se ven bien por fuera pero que en realidad no significan nada
  • Las malas pruebas son más peligrosas que no tener pruebas. Una vez que se rompe la confianza, se derrumba la fe en toda la suite de pruebas
  • Por eso el mutation testing es importante. Si el código cambia y las pruebas siguen pasando, entonces son malas pruebas
  • Se le puede pedir a la IA que modifique intencionalmente partes del código y comprobar si las pruebas fallan. Si no fallan, son pruebas inútiles
  • Claro, tampoco es fácil lograr que un humano escriba ese tipo de pruebas

• Cada vez que sale una nueva generación de LLM, da la impresión de que todas las lecciones anteriores quedan invalidadas
  Estructuras complejas como LangChain, creadas para esquivar las limitaciones de modelos antiguos, dejaron de ser necesarias después de GPT-3.5. Pronto puede que incluso un agente único sea suficiente para encargarse de todo

  • Por eso yo intento ordenar patrones que no dependan de la versión del modelo. Por ejemplo, el TDD red/green quizá pronto lo haga solo el modelo, pero el concepto en sí sigue siendo útil
  • Al final, puede que todo termine convergiendo en algo como ClaudeVM
    Ver artículo relacionado

• Hay algo que suele faltar en la discusión sobre ingeniería de agentes
  La mayoría de las lecciones se presentan como si fueran verdades universales, pero en realidad cambian según el tamaño del equipo, la madurez del codebase, el nivel de pruebas y la tolerancia al riesgo. Lo importante es dejar claro “cuándo funciona este patrón”

  • Por eso estoy organizando los patrones en formato de sitio web en vez de libro. La idea es seguir actualizándolos e indicar explícitamente su ámbito de aplicación
  • Como consultor, al trabajar con varios codebases, veo que el rendimiento de Claude Code cambia de forma extrema según la calidad del codebase. En proyectos con tipado fuerte y pruebas funciona casi perfecto, pero en entornos de JavaScript laxo no tanto
  • Aun así, algunos patrones sí son universales. Por ejemplo, tener una source of truth independiente (harness) sirve en cualquier contexto. Herramientas como showboat y rodney ayudan con eso

• Hoy en día salen decenas de “frameworks de equipos de agentes” cada día
  Es una fase caótica de experimentación, como en los inicios de la ingeniería de software. Pero al final, algunos patrones terminarán estableciéndose como estándar.
  En nuestro equipo nos funcionó bien abordarlo como un equipo humano: primero escribimos una especificación de producto (spec), luego la refinamos con IA y, a partir de eso, la pasamos a un flujo de agentes con roles separados

• Hoy en una clase de pregrado di una charla sobre la evolución de las arquitecturas de CPU y GPU
  Antes, gracias a Moore’s Law, el hardware resolvía todo, pero ahora la clave es la paralelización.
  La idea de Simon de que “el código es barato” es un cambio de paradigma parecido.
  Así como en la era del hardware paralelo cambió por completo qué se considera código eficiente, en la era de la IA va a cambiar el proceso de desarrollo mismo. Quien lo entienda primero obtendrá una ventaja de 10 a 100 veces

• En nuestro equipo, lo más práctico ha sido un loop con validación humana intermedia
  Los agentes totalmente autónomos a veces pasan las pruebas, pero rompen invariantes implícitos.
  Por eso hacemos que un humano intervenga justo antes de decisiones irreversibles.
  Aun así, lograr que la IA entienda “qué es irreversible” es otro reto.
  Además de documentos como CLAUDE.md, estamos buscando una forma sistemática de transmitir las reglas implícitas del codebase