Si también eres lector de mi newsletter The Optimist Engineer, ya habrás recibido el email en el que comunico algo similar.

Este mes de agosto será de descanso y, por lo tanto, no recibirás la edición de esta newsletter hasta septiembre.

Esta es una práctica que me he autoimpuesto en los últimos años, ya que me funciona muy bien para descansar en profundidad, recordar las cosas importantes de la vida y volver con más energía en septiembre.

Si puedes, te recomiendo encarecidamente que hagas lo mismo. Al menos durante 2 semanas seguidas, desconecta completamente de la tecnología.

En los últimos años, he visto a más personas con problemas de estrés, sobrecarga cognitiva y agotamiento.

No quiero que te pase eso. Quiero que estés lo más sano posible, así que quiero aportar mi granito de arena.

A cambio de no recibir esta newsletter en agosto, te contaré mi truco cuando tenga dos semanas de vacaciones:

1. Guarda el portátil en la mochila.

2. Y guarda la mochila en el armario.

Hazlo, ya me darás las gracias 😉.

Cuidate,
Marcos.

Las herramientas que estoy construyendo, ¿se están utilizando de verdad?

Porque el escenario típico es este:

• MCPs instalados, perfectamente integrados.

• SKILLs que funcionan, ¿verdad?

• Agentes que se usan, en teoría.

👉🏼 Tienes que poder distinguir las herramientas que se usan de las que solo están instaladas.

Y aquí aparece la pregunta incómoda:

Si mañana eliminas la mitad de esas herramientas… ¿sabrías cuáles te van a reclamar los desarrolladores?

Respuesta corta: Necesitas instrumentar el momento de ejecución de cada herramienta dentro del editor.

Cada vez que alguien use un MCP, SKILL o agente, debes generar un evento y enviarlo a un sistema de analítica interno.

Respuesta larga: El punto clave no es saber si se usa Claude Code o Cursor. Eso ya lo puedes medir con herramientas tipo Jellyfish, la cual te sirve para saber cuál es la plataforma a la cual vas a reservar budget para el año mes que viene.

¿Y qué hay de las herramientas que los desarrolladores usan dentro de Claude Code o Cursor?

• Qué MCPs se ejecutan realmente.

• Qué skills aparecen en el día a día.

• Qué agentes se usan de verdad frente a los que solo existen en documentación.

• O qué herramientas desaparecerían mañana sin que nadie lo notase.

👉🏼 Eso es algo que necesitas medir, para saber realmente dónde invertir el tiempo de desarrollo.

Esto ya de por sí es un aprendizaje que te llevas. Pero no te voy a dejar ahí.

A continuación te cuento cómo conseguir medir el uso de las herramientas dentro de las plataformas Claude Code y Cursor.

El patrón que necesitas implementar

Si quieres resolver esto, el diseño es siempre el mismo: hooks en el editor + eventos de telemetría.

Instala un hook único en Claude Code y Cursor que capture cualquier invocación de herramienta.

A partir de ahí, cuando se ejecuta una herramienta (MCP, skill, agente o plugin), el hook genera un evento con un esquema mínimo:

• nombre de la herramienta

• tipo de herramienta

• editor (Claude Code o Cursor)

• timestamp

• UUID anónimo de instalación

¡Y ojo con el PII!, no queremos datos que sean sensibles a nivel de seguridad, y por supuesto:

☝🏼 Nada de prompts.
☝🏼 Nada de código.
☝🏼 Nada de contexto del modelo.

No queremos medir comportamiento sino adopción.

Y a partir de que tenemos el evento, ¿qué?

Ese evento se envía a un backend interno (por ejemplo ai-plugins-adoption-api), donde:

1. Se valida el payload.

2. Se registra el evento.

3. Se integra en el pipeline de datos.

A partir de ahí, puedes construir métricas en tu sistema de observabilidad:

• Invocaciones por herramienta.

• Usuarios únicos por MCP / skill / agente.

• Frecuencia de uso.

• Evolución semanal.

👉🏼 Y empiezas a ver algo que no tenías antes: la cruda realidad.

A continuación, te cuento lo que aprendí teniendo un sistema como este funcionando.

Qué vas a descubrir cuando lo implementes

Hay tres patrones que aparecen casi siempre.

☝🏼 El primero me sorprendió, pero puede tener sentido:

La mayoría de herramientas más usadas no son internas, sino las ya existentes en la comunidad.

Como son:

• SKILL de git-commit, para hacer commits y pull requests.

• MCP de SonarQube, para que se revise si el código cumple con las Quality Gates.

• SKILLs de Atlassian, para consultar/crear/actualizar tickets de Jira o páginas de Confluence.

Y tiene sentido, en mi opinión, porque son herramientas para hacer cosas que, a los developers, no nos gusta hacer.

✌🏼 El segundo no lo ví venir en absoluto:

Primero se usan los agentes nativos de la plataforma y luego, ya si tal, otros.

Puede tener sentido, en mi opinión, porque la plataforma siempre va a querer priorizar el uso de sus skills y agentes, y así demostrar el valor que te la dicha plataforma.

👉🏼 Un caso muy común que he visto es el agente Plan de Claude Code. Si desarrollas un agente para que elabore un plan de trabajo para ser leído por humanos, lo tienes complicado. Claude va a decidir usar su propio agente, en la mayoría de los casos, y van a tener que ser los desarrolladores humanos los que van a tener que taggear el uso de tu precioso agente de planificación de trabajo.

En Claude Code verás cosas como:

• Explore, para navegación del sistema de archivos.

• general-purpose, para tareas genéricas.

👉🏼 Antes de construir agentes complejos, necesitas entender qué porcentaje del problema ya está resuelto por la plataforma que uses. Preguntate:

El agente que necesito, ¿está ya implementado?

🖖🏼 El tercero es técnico:

Claude y Cursor no son consistentes en cómo emiten eventos.

• Nombres de skills distintos.

• Estructuras de payload diferentes.

• Niveles de detalle variables.

👉🏼 Si quieres escalar esto fuera de una sola organización, falta un estándar claro de instrumentación, como sí tentemos el protocolo MCP. De momento no lo hay para este tipo de eventos, o yo no lo conozco.

Tengo una pregunta para tí

¿Estarías interesada/o en conocer cuales son los datos, acerca de las herramientas usadas, que puedes obtener de Claude Code y Cursor?

📧 ¡Sí, quiero!

Hoy te he traído una lectura bastante amplia. Déjame un comentario para saber qué te parece esta longitud y profundidad.

Venga, vamos cerrando por hoy.

✨ Takeaways

Si mañana eliminas la mitad de los MCPs, skills y agentes de tu organización, necesitas saber cuáles romperían el flujo de trabajo… y cuáles nadie echaría de menos.

Tu objetivo como desarrollador de software es construir herramientas que dan valor.

La conclusión es:

• La adopción real de herramientas de IA se mide en invocaciones.

• Los hooks centralizados simplifican la observabilidad a escala.

• La mayoría de las herramientas externas maduras ya tienen más uso del esperado.

• Los agentes nativos del editor ya cubren gran parte del uso real, así que sé inteligente acerca de los que tienes que construir para la casa.

👉🏼 Si no puedes medir invocación real, no puedes tomar decisiones acerca de donde invetir el tiempo dinero.

Ahora, como siempre, me gustaría saber más de ti. ¿Estás desarrollando SKILLs para tu equipo? ¿Cuál ha sido tu experiencia usando agentes desarrolladores por tu empresa? Responde a este email o excribe un comentario, ¡los leo todos!

Hace poco, una compañera, vamos a llamarla Silvia, me contaba el caso de su equipo. Gestionan una herramienta llamada Performance Reporter que centraliza métricas de rendimiento de aplicaciones en producción.

El flujo era el de “toda la vida”:

• recolectar datos,

• aplicar lógica de negocio

• y escupir un dashboard en Power BI para que los Engineering Managers entendieran qué estaba pasando.

¿El resultado? Frustración.

Los usuarios no entendían de dónde salían los valores ni cómo se calculaban. Sentían que miraban una “caja negra”.

Silvia lanzó una encuesta, de cara a entender mejor cuáles podrían ser las soluciones al problema, y añadió una pregunta casi por instinto:

¿Te gustaría disponer de un AI Agent (tipo Claude Code o Cursor) para obtener información y entendimiento cuando quieras?

La respuesta fue un 100% de SÍ.

Y, ¿qué significa esto?

El fin del “Te lo cuento yo”

Estamos viviendo un cambio de paradigma.

👉🏼 Los usuarios ya no quieren que el dueño de los datos decida qué es importante para ellos a través de un gráfico estático. Lo que quieren es usar sus propios asistentes de IA para acceder a información personalizada y obtener entendimiento en tiempo real.

Ya no se trata de ver datos; se trata de interactuar, de conversar con ellos.

Si echamos un ojo a lo que se cuece en la industria, podemos ver que, en lo referente a la tasa de adopción anual de la IA entre 2024 y 2025 de un 13–14% a ~20%.

☝🏼 Esto encaja con el resultado de la encuesta de Silvia.

Fuera de las estadísticas, en mi experiencia, el verdadero salto está en el Engineering Management. Para este rol, la IA se está convirtiendo en la herramienta principal para analizar la salud de los sistemas y la eficiencia de los equipos.

Estamos pasando de un modelo donde los datos son un “destino” (el dashboard) a un modelo donde los datos son el “combustible” para la IA del cliente.

¿Qué significa ser AI Native en Plataforma?

Para ti, que estás en las trincheras de la ingeniería, esto cambia las reglas del juego. Significa que tu trabajo ya no es pintar la información, sino exponerla de forma que una IA pueda consumirla.

En este nuevo escenario, el paradigma cambia así:

• Antes: El dueño de los datos te los presenta en la forma que considera mejor para ti.

• Ahora (AI Native): El dueño de los datos los deja a disposición de tus clientes de IA para que consuman la información como tú quieras.

✨ Takeaways

Aquí te dejo los puntos clave para que te ayuden a pensar en modo AI Native:

1. Prioriza la disponibilidad sobre la visualización: Invierte menos tiempo en el color del gráfico y más en que tus APIs y modelos de datos sean legibles y contextuales para un agente de IA.

2. Transparencia total: La IA necesita saber el cómo y el por qué. Si no expones la lógica de tus cálculos, el agente no podrá explicarle nada al usuario.

3. Adopción vertiginosa: Los Engineering Managers y Directores de Ingeniería están saltando a estas herramientas a una velocidad enorme. O bien preparas tus datos para ellos, o tu plataforma quedará obsoleta.

Como siempre digo, aquí aprendemos de lo que vemos en el mundo real. ¿Estás ya preparando tus herramientas para ser consumidas por agentes de IA o sigues puliendo ese dashboard que nadie mira?

Me encantaría saber tu opinión. ¿Has notado este cambio en tu equipo? ¡Escríbeme o deja un comentario! Leo y respondo a todos.

No estamos inventando la rueda. Estamos empaquetando mejor el índice.

¿Te suena?

Ese momento en el que alguien vende “ecosistema” y, en realidad, detrás hay un JSON con enlaces bien puestos.

Vamos al turrón.

☝🏼 ¿Qué es un marketplace?

Respuesta corta:

Un marketplace es un índice.

Respuesta larga:

Es una forma de decirle a un cliente de IA dónde están las piezas que puede usar, cómo encontrarlas y cómo navegar entre ellas.

Y aquí está la gracia.

Hablamos de plugins, es decir, paquetes con skills, agentes, utilidades, automatizaciones y cualquier bloque reutilizable que una IA pueda descubrir y consumir.

Es la misma lógica que tenían los viejos índices de contenidos en la web primitiva. Sí, el patrón se repite, como el chorizo en una paella.

Solo que ahora, en vez de un humano haciendo clic, quien recorre el catálogo es Cursor, Claude Code o el cliente de turno.

Pero, ojo a esto:

👉🏼 La clave no es el marketplace. La clave es la distribución.

1. Porque una cosa es tener capacidades internas.

2. Y otra muy distinta es hacer que el resto de la organización las encuentre, las entienda y las use sin abrir un ticket, sin preguntar por Slack y sin perder media mañana.

El problema

Seamos sinceros: la mayoría de organizaciones siguen pensando en IA como si fuese una herramienta más y, como te estarás imaginando, eso no escala.

La aproximación IA Native cambia el proceso, no solo el software, y este caso no es una excepción.

En el modelo legacy (llámelo así), si querías reutilizar algo, lo documentabas, lo mandabas por email, cruzabas los dedos y rezabas para que alguien lo leyera. Bueno, en realidad, algunos aún hacemos esto para algunas cosas.

Ahora, en la era de AI Native, si quieres escalar de verdad, necesitas que la IA pueda descubrirlo y consumirlo sola. Ahí es donde patina el modelo legacy.

Porque el problema ya no es “tenemos o no tenemos la SKILL”.

El problema es:

• ¿La IA la encuentra?

• ¿La entiende?

• ¿La usa sin fricción?

• ¿Está actualizada?

• ¿O vamos a seguir viviendo de “pregúntale a Paula, que se sabe cómo va esto”?

☝🏼 El cuello de botella ya no es técnico. Es cultural y de empaquetado.

Llevo una temporada trabajando en este problema y hoy comparto contigo lo que estamos haciendo en mi equipo para solucionarlo. Si te animas a darme feedback, sería genial.

Arquitectura de dos niveles de marketplace

En mi experiencia, la jugada buena no es hacer un único mercado gigante y esperar milagros.

Por ello propongo distribuirlo en capas.

1. Marketplace general

Este es el escaparate común para toda la organización de ingeniería.

Este marketplace general cubrirá 2 necesidades de desarrollo de software para los equipos de desarrollo.

Prácticas del desarrollo de software.

Aquí metes (SKILLS, agentes, plugins) lo que sirve para casi todo el mundo:

• Diseño y arquitectura del software.

• Revisiones de código.

• Generación de planes.

• Soporte para pull requests.

• Challenge de decisiones técnicas.

• Helpers de documentación.

Todo eso que acelera al equipo sin depender de “quién lo sabe”.

Ahora, la segunda necesidad.

Capacidades de equipos concretos.

En este mismo marketplace, tendremos plugins para funcionalidades que ofrecen equipos de plataforma, concretos del contexto de tu empresa, para ser usados también por los equipos de desarrollo.

Por ejemplo:

• Integración con una API interna.

• Acceso a recursos custom de Kubernetes.

• Automatizaciones del platform team.

• Utilidades del equipo de seguridad.

• Wrappers sobre servicios corporativos.

Esto es importante porque muchas veces el valor real está ahí.

No en lo “genérico”. Sino en lo que un equipo crea una vez y el resto reutiliza veinte veces.

2. Marketplace de equipo

Y luego está el nivel que muchos subestiman: el marketplace propio de un equipo.

No para venderlo al resto de la empresa, sino para que ese equipo tenga sus propias piezas AI Native, sus propios atajos y su propio onboarding inteligente.

Porque no todos los equipos trabajan igual, no todos necesitan las mismas SKILLS, y no todas las burbujas de la organización tienen por qué vivir de un catálogo universal.

¿Por qué esta estrategia de 2 niveles de marketplace funciona?

Porque conviertes el conocimiento en algo navegable, reutilizable y gobernable.

Y eso, en la práctica, significa tres cosas muy potentes:

Primero, reduce la dependencia de personas concretas. Si una habilidad vive en un marketplace, no depende de que alguien la recuerde.

Segundo, mejoras el onboarding. Un nuevo dev no tiene que adivinar cómo se hacen las cosas. La IA le enseña el camino.

Tercero, permites flexibilidad a los equipos para adaptar su estilo de desarrollo, desde el plano general gobernado por la organización de ingeniería, al plano concreto dentro de cada equipo.

Cuarto, consigues el ownership que consigue que los plugins no queden desactualizados, ya que el equipo de plataforma se encargará de los plugins generales y los equipos de los comunes y específicos.

Quinto, aceleras la adopción real de IA. No en PowerPoint. No en una demo bonita.
En el día a día.

☝🏼 La adopción de IA no se gana con entusiasmo. Se gana con infraestructura útil.

✨ Pro Tip

No empieces el marketplace por el catálogo.

Empiézalo por el dolor.

👉🏼 Pregúntate:

• ¿Cuál es el ciclo de desarrollo de software de los equipos?

• ¿Qué capacidades están ofreciendo a día de hoy, a través de páginas de Confluence, los equipos entre ellos?

• ¿Qué podría ejecutar una IA mejor si tuviera la pieza adecuada?

• ¿Cómo podemos ser más efectivos y eficientes?

• ¿Qué cosas nos hacen perder tiempo de verdad?

Ahí tienes el material bueno.

Y otra pregunta que estoy seguro que te ronda la cabeza:

¿Cojo plugins, SKILLS, agentes de paginas como skills.sh o las creo yo?

No tengo una respuesta clara por los siguientes motivos:

• Las SKILLS y plugins que hay en la red pueden tener problemas de seguridad, y ya te digo yo que tu equipo de seguridad no va a poder revisar cada uno de los que quieras probar, no escala.

• Por otro lado, lleva mucho esfuerzo e iteración redactar tus propios plugins. Si ya tienes eso documentado en algún sitio, será más fácil transformarlo en plugins de marketplace.

Así que te digo lo que hago yo:

1. Las más generales, las descargo de la red y hago que la IA las revise, que las audite, en busca de posibles agujeros de seguridad.

2. Para las más concretas, como por ejemplo un plugin para conectarse a nuestra instancia de SonarQube y hacer comprobaciones de calidad, pues las escribo yo… con IA.

Vamos cerrando por hoy …

El reto que tenemos ahora con SKILLS, agentes y demás, es empaquetar capacidades para que la IA las encuentre y las use bien.

Tienes que plataformizar su uso, y lo antes posible, porque los equipos de desarrollo ya están haciendo sus cositas.

¿Qué enfoque te parece más útil en tu organización: un marketplace general, uno por equipo o una mezcla de ambos?

Sip, tiene sentido empaquetar procedimientos reutilizables en un formato instalable.

Una vez empecé a instalar skills y vi en lo que consistían de verdad, la frase que me salió fue:

Pero esto, ¿en qué se diferencia de un archivo AGENTS.md?

Y este es el tema principal de la edición de hoy para la newsletter 👉🏼 ¿Merece la pena cargarnos, como desarrolladores de software, con un nuevo framework?

Pero, como dijo alguien, vamos por partes.

Primero, y brevemente, ¿qué son las SKILLS?

☝🏼 Las Skills son paquetes (una carpeta) reutilizables de conocimiento procedimental que enseñan a un agente de IA cómo ejecutar tareas concretas (no sólo qué decidir). Piensa en ellas como manuales operativos o plugins para asistentes de programación: instrucciones, ejemplos, scripts, plantillas y recursos que el agente puede cargar y seguir para realizar tareas repetibles.

Ahora, la pregunta clave no es si las Skills existen ni si están bien diseñadas.

La pregunta es: ¿aportan algo que no podamos obtener ya con AGENTS.md y algo de disciplina?

👉🏼 No hay ningún problema técnico fundamental que SKILLS resuelva y que no puedas resolver con AGENTS.md más disciplina y procesos.

Lo dicho, vamos por partes.

1️⃣ Mismo contenido funcional

Lo valioso de una Skill es su conocimiento procedimental: pasos concretos, ejemplos de entrada y salida, scripts ejecutables y reglas de permisos.

Si usas AGENTS.md como índice o como documento primario con inputs, outputs, ejemplos y enlaces a scripts versionados, estás cubriendo la misma funcionalidad práctica.

2️⃣ Menos complejidad operativa

Los desarrolladores de software tenemos cada vez más carga cognitiva. Con la aparición de la IA generativa, esa carga no ha disminuido, sino que ha aumentado.

¿En serio necesitamos otro framework más?

Instalar npx skills add ... y mantener un ecosistema distribuido introduce:

• un CLI más que aprender,

• dependencias externas (supply-chain),

• y un modelo de permisos a revisar.

Si tu equipo trabaja dentro del repo y controla el CI/CD, mantener AGENTS.md es más simple.

3️⃣ Lo que SKILLS solucionan “de serie” y cómo replicarlo

Es cierto que SKILLS ofrecen por defecto tres cosas que con AGENTS.md hay que construir:

• Distribución y descubrimiento estandarizado entre múltiples repos y equipos.

• Instalación declarativa, con versiones independientes del repo consumidor.

• Interoperabilidad si varios agentes adoptan el mismo estándar.

En caso de que lo necesites, puedes replicarlo con AGENTS.md si añades:

• Un repo central o índice, un pequeño instalador que descargue la versión marcada, tags/releases semánticos,

• CI que exporte artefactos y un job que genere SKILL.md si hace falta compatibilidad externa.

Es trabajo extra, pero es trabajo que tu equipo puede automatizar y controlar desde Git.

👉🏼 Mi consejo: empieza con AGENTS.md como código.

Trátalo como tal: PRs, tests, tags y changelog. Indica en el propio AGENTS.md que el agente de IA se encargue de actualizarlo cuando haya cambios significativos en la aplicación.

Si algún día necesitas distribución masiva, automatiza la exportación a SKILL.md desde tu pipeline. Así te ahorras la fricción inicial y mantienes la puerta abierta.

¿Qué opinas de todo esto? Me encantaría saber tu opinión y tu experiencia usando SKILLS y AGENTS.md, así que no dudes en responder a este email, dejando un comentario en Substack, o dame un toque a través de BlueSky.

¿Te ha gustado la edición? Compártela con alguien que esté liado con esto 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

Ostras, vaya cantidad de código, ¿en serio me tengo que poner a revisar todo esto?

¿Te ha pasado?

Esto es un problema.

Y sobre todo cuando a mis compañeros humanos les aburro todo el día con el discurso:

Chavalada, a ver si podemos hacer Pull Requests más pequeños, que se revisan mejor y así aumentamos la calidad del software.

☝🏼 Pero recientemente me he dado cuenta de que estoy programando siguiendo flujos AI Native, mientras que sigo haciendo las revisiones de código a la vieja usanza (¡de hace apenas 2 años!).

En la edición de hoy os voy a explicar una nueva aproximación a las revisiones de código generado por los Agentes de IA y consiguiendo los mismos objetivos que con una revisión de código estándar.

☝🏼 Empecemos por el principio: ¿Qué se persigue en un Code Review?

Cuando una persona revisa código que debe ir a producción, ha de asegurarse de que:

1. Se implementa lo que hay que implementar, es decir, el código satisface los requisitos.

2. Se implementa con calidad, es decir, el cambio no introduce bugs y el código es mantenible.

A partir de aquí, ya existen estudios [1] que indican que la cantidad de código generado por los Agentes de IA es mayor que la generada por desarrolladores humanos.

👉🏼 Y esto implica más código a revisar en los Pull Requests correspondientes.

Esto no escala.

Con tanto código a revisar en los Code Reviews, el producto software se ve significativamente impactado, ya que es más difícil conseguir los objetivos del mismo.

☝🏼 Tenemos que cambiar la aproximación, manteniendo al humano en el proceso, ya que es el último responsable de ese código que va a ir a Producción.

Una aproximación AI Native.

Y aquí viene la propuesta que te traigo y está funcionando en los equipos con los que estoy trabajando:

• No revises el código de la IA,

• Revisa la decisión tomada por la IA.

Y me explico.

Piensa en el siguiente flujo de trabajo.

1. Le pides a tu Agente de IA que haga un plan para implementar una feature nueva o arreglar un bug (por ejemplo).

2. Iteras el plan, le preguntas, quieres que el plan sea lo más sólido posible, siguiendo las buenas prácticas que aplican para tu empresa o al repositorio sobre el que estás trabajando.

3. Finalmente, le das luz verde al agente para implementar el plan.

4. Y, además del código, en tus instrucciones le indicas que te genere un Architecture Decision Record (ADR) para la implementación elegida, que además será incluido en el Pull Request.

Ahora, advinida qué es lo que tú y tus revisores del Pull Request, como humanos, vais a revisar. Exacto.

👉🏼 Como humano, revisas el archivo de texto donde se explica la decisión técnica que se ha implementado, no el código.

¿Qué se consigue con esta aproximación?

• Uno de los 2 objetivos de una Code Review estándar, ya que estás leyendo qué ha cambiado, con lo que te aseguras de que se implementa lo que hay que implementar.

• La revisión de cambios (que no de código) ya escala, es decir, ya no tienes que navegar entre un montón de cambios en el diff que del Pull Request en GitHub/GitLab.

👉🏼 ¿Lo has notado? Ya no hablo de “revisión de código”, sino que hablo de “revisión de cambios”

Pero ojo, hay algo que pierdes (?).

¿Entra en la definición de código mantenible el código generado por la IA? Pues depende lo fino que hayan sido tus prompts o la información que hayas puesto en el archivo AGENTS.md. La realidad es que, como no revisas el código, no lo sabes con seguridad. Pero dejo la siguiente reflexión en el aire para que me respondas por email o en un comentario en Substack:

En la dirección en la que vamos con los agentes de IA generando nuestro código, ¿cuán importante es que el código sea mantenible si va a ser la misma IA quien lo va a volver a modificar en el siguiente cambio?

Ahí lo dejo.

Y hasta aquí la edición de hoy en la que te he tratado de explicar una aproximación AI Native a la revisión de código cambios generados por agentes de IA.

Si me preguntas cuál sería, en una frase, el aprendizaje de hoy, sería:

👉🏼 Cambia la orientación de revisión de código por revisión de cambios.

Me encantaría conocer tu opinión al respecto. ¿Tienes problemas para revisar código generado por la IA? ¿Qué soluciones estás poniendo en práctica para asegurar que el código generado por la IA haga lo que tiene que hacer?

Si conoces a alguien a quien le pueda interesar este tema, reenvíale este email o dale al botón de compartir 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

No son intercambiables. No son lo mismo.

Y mezclar sus responsabilidades es la vía rápida a incidentes, discusiones de permisos y dolores de cabeza legales.

En una futura edición os contaré los casos de uso para subagentes y para MCP servers.

En la edición de hoy de la newsletter, vas a aprender la diferencia entre subagentes y MCP servers, y cómo implementar el framework de subagentes. En concreto:

• Qué es un subagente.

• Qué es un MCP server.

• Cómo puedo empezar a usar subagentes.

🎁 ¡Atención! La edición de hoy viene con regalito 🎁. Al final de este email puedes encontrarlo.

Para ir entrando en calor, y por si te lo perdiste, este artículo sobre el framework AGENTS.md te puede resultar de utilidad como contexto para seguir con la lectura de la edición de hoy.

Ahora, vamos a turrón.

Qué es un subagente y un MCP

Un subagente es un rol cognitivo especializado:

• Tiene un prompt,

• razona dentro de un scope,

• y devuelve outputs estructurados.

Piensa en él como un especialista senior que recibes por texto y que responde con juicio técnico.

Las características principales se pueden enumerar como:

• Objetivo propio.

• Razonamiento autónomo dentro de un scope.

• Puede llamar a tools (MCPs), pero decide qué y cuándo.

• Devuelve outputs con estructura (JSON, checklist, diff de código, etc.).

👉🏼 Los subagentes son conocimientos, prompts, usados y orquestados por tu agente de IA (gpt 5.2, Claude Opus 4.6, etc.).

Por otro lado.

Un servidor MCP (Model Context Protocol) es una aplicación: un adaptador que expone capacidades, datos y herramientas al agente.

No razona: responde llamadas con datos tipados y funciones (p. ej. “searchLogs”, “createPR”, “queryMetrics”).

Las características principales se pueden enumerar como:

• API y contratos tipados.

• Control de permisos y auditoría.

• Determinista: realiza acciones concretas cuando se le pide.

• No tiene prompt ni toma decisiones por sí mismo.

Quédate con la siguiente idea 👇🏻

• Subagente → piensa + decide.

• Servidor MCP → ofrece capabilities + acceso a datos

Ahora bien, centrándonos en los subagentes.

Cómo puedo empezar a usar subagentes

Mucha información general y poca concreción, ¿verdad? Bueno, era necesaria para que podamos seguir.

Vamos al detalle.

👉🏼 Como puedes ver, al final del día implementar un subagente cognitivo es organizar conocimiento en diferentes archivos Markdown.

No obstante, la primera vez que te enfrentas a ello, puede ser un poco confuso; uno no sabe qué poner en AGENTS.md y qué poner en los archivos dedicados a los subagentes.

☝🏼 Algo que tienes que tener en mente:

1. AGENTS.md se inyecta automáticamente en el contexto del agente en cada conversación. Si es largo, consume innecesariamente tokens con información que puede no ser relevante para la tarea actual.

2. Los subagent files se cargan bajo demanda, solo cuando el agente determina que son relevantes.

Y, ¿en qué se traduce esto? Te cuento cómo veo que funciona mejor.

La mejor práctica es que AGENTS.md sea lean pero no vacío; básicamente, un índice. Debe contener:

1. Project overview (2-3 líneas max): contexto universal.

2. Critical rules que aplican a CUALQUIER tarea (naming, arquitectura core, patrones prohibidos).

3. Quick commands: el agente los necesita constantemente.

4. El índice de subagents con descripción clara de CUÁNDO usar cada uno.

Todo lo que solo es relevante en contextos específicos: detalles de seguridad, CI/CD detallado, guías de test exhaustivas, etc. Eso va en los subagents.

Venga, te cuento cuál es la estructura ideal 👇🏻

AGENTS.md (~80-100 líneas)

├── Project title + 2-line description

├── Architecture invariants (las reglas que nunca se rompen)

├── Quick commands block

└── Subagent index:

 ├── subagent_architecture.md → “Use for: new features, design decisions”

 ├── subagent_build_test.md → “Use for: build issues, test creation”

 ├── subagent_configuration.md → “Use for: env setup, Kafka config”

 ├── subagent_code_style.md → “Use for: code review, formatting”

 ├── subagent_ci_pr.md → “Use for: PR creation, CI failures”

 └── subagent_security.md → “Use for: secrets, auth, encryption”

Puede ser que algunos de esos Markdowns no apliquen en tu caso, pero pillas la idea.

El elemento clave 👇🏻

El AGENTS.md debe instruir explícitamente al agente cuándo cargar cada subagente. Sin esto, el agente puede ignorarlos. Algo así:

## Subagent Files

Before starting any task, identify which subagent files apply and read them:

| File | Read when... |

|------|-------------|

| `subagent_architecture.md` | Adding features, refactoring, design questions |

| `subagent_build_test.md` | Running builds, writing/fixing tests |

| `subagent_configuration.md` | Setting up env, changing Kafka topics, config |

| `subagent_code_style.md` | Writing new code, reviewing PRs |

| `subagent_ci_pr.md` | Creating PRs, debugging CI pipeline |

| `subagent_security.md` | Handling credentials, auth, sensitive data |

Esos subagentes son ejemplos y algunos de ellos son los que uso yo. En tu caso igual no aplican todos, o algunos sí, y seguramente tendrás que crear unos para tu caso.

No obstante, siguiendo el ejemplo de arriba, ahora te cuento lo que debe contener cada uno de esos archivos Markdown.

subagent_architecture.md

• Patrones arquitectónicos detallados (Arquitectura Hexagonal, Basada en Eventos, DDD).

• Arquitectura de componentes con ejemplos de código.

• Puntos de extensión para añadir nuevas funcionalidades.

• Consideraciones y monitorización del rendimiento.

• Pruebas de patrones arquitectónicos.

subagent_build_test.md

• Documentación completa del sistema de compilación.

• Estructura y estrategias del marco de pruebas.

• Directrices para pruebas de rendimiento.

• Problemas comunes de compilación y soluciones.

• Controles de calidad y requisitos de cobertura.

subagent_configuration.md

• Configuración del entorno y prerrequisitos.

• Configuración de temas de Kafka.

• Gestión dinámica de la configuración.

• Supervisión y comprobaciones de estado.

• Solución de problemas de configuración.

subagent_code_style.md

• Prácticas recomendadas y características modernas de Java 21.

• Guías de uso de Lombok.

• Estándares de organización de paquetes.

• Patrones de gestión de errores.

• Estándares de documentación y pruebas.

subagent_ci_pr.md

• Configuración de la canalización de CI/CD de GitHub Actions.

• Flujo de trabajo y plantillas de solicitudes de incorporación de cambios.

• Procesos de protección y revisión de ramas.

• Procedimientos de implementación y monitorización.

• Solución de problemas de CI/CD.

• Sintaxis para crear commits y Pull Requests.

subagent_security.md

• Directrices de seguridad integrales.

• Gestión y rotación de secretos.

• Validación de entradas y protección de datos.

• Supervisión de la seguridad y respuesta a incidentes.

• Requisitos de cumplimiento y auditoría.

Ves por dónde va la cosa, ¿verdad?.

A partir de aquí, teniendo esos archivos en tu directorio de trabajo, cada iteración que tengas con tu agente de IA, éste sabrá por dónde navegar y qué añadir a su contexto, en función de tus peticiones.

Y todo esto, ¿para qué?

👉🏼 Con el framework de AGENTS y subagentes, puedes esperar:

1. Ahorrar tokens, a.k.a dinerito 💸

2. Mejores resultados en las respuestas e implementación del código generado por los asistentes de IA.

Espero que te haya gustado la edición de hoy.

Me encantaría conocer tus experiencias implementando y utilizando subagentes y MCP Servers. Responde a este email, deja un comentario en Substack o dame un toque por redes sociales.

🎁 Regalito

Tengo un meta prompt que, pasándoselo a tu asistente de IA, te va a crear todos los archivos necesarios para que implementes, en un ENTER, toda la infraestructura para empezar a usar subagentes en tu aplicación.

¿Lo quieres gratis?

Muy fácil:

• Bien responde a este email,

• O mándame un email a hola@ainative.es,

• O dame un toque por Bluesky/Mastodon

Y te lo mando.

Si conoces a alguien a quien le pueda interesar el tema de AGENTS.md y subagentes, reenvíale este email o dale al botón de compartir 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

¡Los developers seremos los primeros en usar esto!

Y no fue así.

Eso enseña algo básico:

👉🏼 La adopción de IA en una compañía no es sólo técnica, sino que es cultural.

Y si quieres que sea segura y útil para tu producto SaaS, necesitas un onboarding.

A continuación te dejo la propuesta que empezamos a aplicar en los equipos con los que trabajo, basada únicamente en lo que hemos vivido.

Pero lo primero es lo primero.

¿Por qué necesitas un onboarding formal?

Porque sin él:

• La gente usa agentes sin evaluar seguridad ni legalidad.

• Puedes acabar exponiendo datos sensibles o incumpliendo normas/ISO.

• Los equipos crean silos de “cómo” usar la IA y nadie coordina.

En mi caso, tuvimos que parar y pensar:

¿cómo lo hacemos esto sin liarla?

Pues aquí va mi propuesta, basada en la experiencia por la que pasamos en nuestros equipos.

Mi propuesta

1️⃣ Assessment

¿Qué usos existen ya en la empresa? Marketing y ventas ya usaban herramientas para crear contenido; developers probando Cursor/Copilot.

El equipo de procesos se ocupó de hacer este análisis y realizó encuestas para conocer las necesidades de cada departamento.

2️⃣ Formación mínima para todos

No sólo devs. Hicimos cursos para producto, ventas y RRHH: qué es generativa, límites legales, buenas prácticas.

Esto se hizo en paralelo con el assessment indicado anteriormente.

3️⃣ Elegir herramientas y entender cómo usarlas

En mi caso, optamos por un sistema tipo ChatGPT pero preparado para el uso interno de una empresa (de forma global). Elegimos Nexus AI.

Para desarrollo, hablamos con Cursor, Windsurf, y GitHub Copilot, que además incluyó cursos de formación especifificos, incluyendo para casos de Power Users, en sus herramientas.

4️⃣ Adopción

No adoption, no party. Si no consigues la adopción de un sistema, un proceso o herramientas, es como si no hubieras hecho el trabajo.

Se comunicó repetidamente por email, en meetings globales, etc., acerca de la existencia de las diferentes herramientas disponibles para los trabajadores en general y para los desarrolladores en particular.

Como ves, no es un proceso de onboarding especialmente sofisticado, y es que cuando nos planteamos la adopción de IA para conseguir mejorar nuestra productividad, no encontramos experiencias de onboarding por parte de otras empresas.

Todo se mueve muy rápido, así que hicimos lo que ya hicimos en otras ocasiones, pero orientado a la IA.

✨ Pro Tip para developers

A la hora de empezar a trabajar con un asistente de IA para código, mis recomendaciones son las siguientes:

• Redacta tu prompt como si le estuvieras explicando a un perfil junior (a otro junior si tu perfil es junior) qué es lo que quieres conseguir. No seas abstracto, sé concreto.

• Dale indicaciones acerca de cómo quieres que el código sea estructurado. Me refiero a cosas como arquitectura del software, buenas prácticas, etc.

• Escribe tú los tests y pídele a la IA que escriba el código teniendo en cuenta los tests que has escrito. Tú, como developer, conoces los casos de uso, así que escribe los tests y déjale a la IA el trabajo inicial de implementar. Para saber más acerca de esto, te recomiendo que leas este email: Flujo de Trabajo con TDD y Agentes de IA.

• Y siempre revisa el código que la IA genera.

☝🏼 Empieza con tests y pide al agente que implemente esos tests. Tú sigues siendo responsable; la IA acelera, pero no delegues la responsabilidad.

🎁 Bola extra

Esto es exclusivo para esta edición en español de la newsletter, y si estáis empezando con el desarrollo asistido por agentes de IA, te interesa fijo.

🚨 📣 Estoy muy feliz de contáros que ya que está disponible la entretenida entrevista que me hizo Hernan Diaz Rodriguez, dentro del marco de la Microcredencial en Inteligencia Artificial en la Universidad de Oviedo.

En dicha entrevista, hablamos acerca del desarrollo de software usando los agentes de inteligencia artificial, los trucos aprendidos, cómo empezar con ellos y más cositas.

🧡 Quiero dar las gracias desde aquí a Hernán por la oportunidad de hacer llegar mi voz y mi experiencia a sus alumnos de la Universidad de Oviedo.

Os dejo el enlace al vídeo 👇🏻

¿Te ha gustado la edición? Compártela con alguien que esté liado con esto 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

Tienes una aplicación legacy escrita en Scala, escrita con no muy buenas prácticas de desarrollo de software, que necesitas migrar a Java, usando buenas prácticas.

Hace 3 años, tu solución sería ir, poco a poco, traduciendo código de un lado a otro.

Ahora, en los albores de la IA generativa y de la asistencia al desarrollo de software, ¿podría encargarle esa tarea a un agente de IA?

Respuesta corta: Sí.

Respuesta larga: Sí, pero no como esperas.

En el email de hoy te cuento cuál ha sido la estrategia que me ha resultado ser exitosa para migrar un código legacy de un lenguaje a otro.

Este es un escenario real que uno de los equipos de desarrollo con los que trabajo ha tenido; ¡esta es la vida real!

Primera idea: que la IA lo haga todo

Fracaso.

Esta fue la primera idea feliz que se me pasó por la cabeza:

¿Y por qué no cargamos en el IDE el proyecto viejo y el proyecto nuevo, vacío, y le metemos un prompt potente al agente de IA para que migre todo el código?

Inviable, al menos, hoy en día.

Por muy bueno que sea el prompt, cuando es mucho código, el agente de IA va a perder cosas por el camino; simplemente es demasiado contexto y sabemos que los agentes de IA se pueden marear cuando llevan consigo demasiado contexto.

He hecho alguna prueba con scripts pequeños, de unas 50 o 100 líneas, para migrar de SHELL a Python, y esta aproximación funcionó bastante bien.

Con un proyecto de una dimensión normal o grande, como digo, simplemente no funciona.

Segunda idea: divide y vencerás

Fracaso.

Esta fue la segunda idea feliz que se me pasó por la cabeza:

Vale, no podemos pedirle al agente que lo haga todo a la vez, pues pidámosle por bloques, por paquetes, y así el contexto será menor.

Al no tener toda la visibilidad, simplemente no es capaz de aplicar las buenas prácticas; necesita refactorizar muy frecuentemente y no se da cuenta de ello; se lo tienes que decir tú. Inventa mucho.

Simplemente, no escala.

Tercera idea: abstrae las reglas de negocio para que otro agente las entienda

Éxito.

Esta idea no vino de mí, sino de un compañero del equipo:

Vamos a pedirle al agente de IA que analice el proyecto en Scala y nos saque un documento donde explique cosas como la lógica de negocio, los test de caja negra, funcionales, etc. y con ese documento, vamos a otro agente de IA para que, poco a poco, nos ayude a implementar lo mismo en Java.

¿Por qué nos ha funcionado esto?

• Los agentes de IA se llevan bien con instrucciones en Markdown. También son buenos para traducir código a texto y viceversa y, si además, le pedimos que lo adapte para ser procesado por otro agente de IA, pues mejor.

• Permite que el agente de IA pueda ir implementando por bloques, pero teniendo la visión completa en texto, con lo cual se hace más eficiente.

No os voy a engañar: lleva tiempo y hay que ir poco a poco trabajando con el agente, pero de momento nos está funcionando.

Tips

Para terminar el email de hoy, te dejo unos tips en base al aprendizaje adquirido con este ejercicio.

• Pídele al agente que empiece por implementar los tests. Esta es la aproximación TDD y te ayudará a ti, ser humano, a tener más confianza en que las cosas se están haciendo bien.

• Pídele el plan antes de que lo implemente. Revisa su plan, pídele cambios.

• Pídele cambios poco a poco. Hemos visto en anteriores ediciones que Spec-Driven Development puede funcionar si se produce en lotes pequeños y no se pide toda la funcionalidad de golpe.

• Revisa todos los cambios. En serio, revísalos, que hay veces que el agente patina y no hace las cosas como tú quieres o te cambia un test para conseguir su objetivo.

• Para que use las buenas prácticas, me ha funcionado muy bien el uso de AGENTS.md. Puedes leer más sobre AGENTS.md aquí.

Espero que te sea de utilidad el aprendizaje de la vida real de hoy.

Me encantaría saber si has ya intentado algo similar y si has encontrado limitaciones al programar de la mano de agentes de IA. Responde a este email o deja un comentario.

Si conoces a alguien a quien le pueda interesar este tema, reenvíale este email o dale al botón de compartir 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

¡La nueva frontera! Desde los Specs de tu Product Manager al código implementado por un agente de IA.

Esa es la idea.

Pero te planteo una pregunta: ¿Nos devuelve Specs Driven Development a los tiempos del desarrollo en waterfall?

Primero, empecemos por el aprendizaje de hoy.

📜 ¿Qué es Spec Driven Development?

Spec-Driven Development (SDD) consiste en escribir especificaciones explícitas, ejecutables o fácilmente verificables, antes de escribir el código, y usar esas especificaciones como la fuente de verdad para que herramientas (incluidas IA/LLMs) generen, prueben y validen el software.

En la práctica, GitHub propone tratar Markdown como un “lenguaje de programación” para especificaciones: usar secciones, ejemplos, y bloques que describan comportamiento, API, datos y pruebas.

¿Por qué está ganando tracción?

Con el auge de los asistentes de código, saber describir con precisión lo que quieres se convierte en algo muy útil. La habilidad de redactar especificaciones claras, con ejemplos, criterios de aceptación y casos de prueba, es cada vez más valiosa; permite obtener código más fiable y reproducible de herramientas automáticas.

Si te lo resumiera en 3 pasos, serían:

1. Escribe la spec en Markdown: objetivo, contratos (endpoints, payloads), ejemplos de entrada/salida y criterios de aceptación.

2. Genera y prueba: usa la spec para generar código con un agente de IA o herramientas de scaffolding; valida contra los ejemplos y los tests incluidos.

3. Itera y versiona: la spec evoluciona y actúa como documentación viva y como suite de pruebas.

Si sabes escribir buenas especificaciones, tienes la oportunidad de sacarle mucho más partido a herramientas automáticas y a equipos que trabajan a escala. Como un prompt gigantesco vamos.

Y eso es, sobre el papel, Spec-Driven Development. Hasta aquí el aprendizaje de hoy.

Ahora, la reflexión con la que arranqué el email.

🏞️ ¿Volvemos a Waterfall?

SDD no está destinado necesariamente a devolvernos al waterfall, pero sí puede hacerlo si se aplica mal.

¿Especificaciones muy amplias? No, gracias.

SDD incentiva a escribir especificaciones muy completas antes de implementar. Si la organización exige specs “completas”, eso reproduce el comportamiento típico del waterfall: largos análisis antes de cualquier entrega concreta.

¿Te imaginas tener que hacer un code review de una feature completa implementada por un Agente de IA? Para una POC, tal vez, pero, ¿para código que va a Producción? 😱

¡Pero no hace falta que lo hagamos! Podemos elegir; podemos elegir proveer de especificaciones más pequeñas para que el Agente de IA las procese y desarrolle partes más concretas, más controladas.

¿Qué recomiendo si en tu caso tienes especificaciones grandes?

• Trocea esas especificaciones en pequeños entregables

• Y trabaja cada pequeño entregable con el Agente de IA

Así conseguirás resultados más efectivos, ya que el Agente de IA trabaja mejor con contextos más concretos.

Cuando las specs son ejecutables, como por ejemplo:

• Tests automatizados.

• Contratos que se pueden validar.

• Implementar una lectura de datos desde Kafka.

En esos casos, actúan como feedback rápido. Eso encaja con ciclos iterativos y entrega continua, no con entregas gigantescas.

✨ Conclusión

Lo que quiero que te lleves del email de hoy es qué es Spec-Driven Development:

Una técnica para que los Agentes de IA desarrollen software a partir de unas especificaciones iniciales.

A partir de ahí, he querido abrir un debate en tu cabeza para que puedas esta técnica de una manera que te sea útil.

Alguien dijo una vez (o muchas):

Un gran poder conlleva una gran responsabilidad.

Spec-Driven Development se plantea como un intento para que los Agentes de IA se encarguen de todo, y en tu mano está concretar qué es ese “todo”.

Personalmente, pienso que si se acota y trocean las especificaciones, es decir, se reduce el scope para conseguir entregables pequeños de forma iterativa, es una técnica que nos puede ayudar en nuestras interacciones con los Agentes de IA.

Me encantaría conocer tu experiencia con Spec-Driven Development; ya sea que estés empezando con ello o que ya te hayas rodado con esta técnica. Puedes responder a este email, comentar si estás en Substack, o mandarme un mensaje por redes sociales 👇🏻

• LinkedIn

• BlueSky

• Mastodon

¿Te ha gustado la edición de hoy? Compártela con tus amistades 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

Mira, usa este prompt que hice yo, que a mí me funcionó genial.

Y, efectivamente, ese prompt consiguió que el agente de IA hiciera el trabajo a las mil maravillas. Tal vez fue suerte, el milagro de San GPT, o quién sabe, pero te funcionó y te lo guardas para el futuro.

¿Te ha ocurrido?

En efecto, no eres la única persona a la que le pasa.

La gente comparte y usa prompts sobre nuestras bases de datos sin saber si esos prompts son adecuados para nuestros datos. El resultado es variado:

• Respuestas inconsistentes entre equipos.

• Información incorrecta o incompleta que se filtra a decisiones operativas.

• Mucho tiempo gastado afinando prompts a base de prueba y error.

• Despilfarro de tokens y riesgo reputacional.

En pocas palabras: sin una evaluación reproducible, cada equipo reinventará la rueda y pagará por ello.

Este es un problema que ha escalado recientemente en mi ranking de preocupaciones, y por ello me he puesto a investigar para solucionar este problema.

Como suele pasar, cuando el problema es claro, la solución empieza a tomar forma.

¿Y si hubiera algo que permitiera a una organización saber cuál es el prompt ideal para una determinada tarea?

Evaluación de Prompts

Lo primero que se me ocurrió: Montamos un sistema ad hoc de evaluación automatizada de prompts que haga lo siguiente:

• Ejecutar variantes de un mismo prompt contra varios modelos.

• Medir métricas objetivas: precisión, completitud, tasa de alucinaciones, coste en tokens, formato correcto.

• Clasificar resultados por modelo y por dominio de datos (clientes, facturación, logs, etc.).

• Entregar un ranking claro: qué prompt funciona mejor con qué modelo y para qué tipo de dato.

Con esto, un desarrollador puede escoger la combinación óptima en lugar de adivinar. Además, la evaluación debe integrarse en CI para detectar regresiones cuando cambiamos prompt o modelo.

☝🏼 Pero, ¡ojo!, ¿realmente es necesario que montemos un equipo de desarrolladores que dediquen, ni-se-sabe cuánto tiempo, a desarrollar un sistema ad hoc como este?.

Mi recomendación es que no; evita implementar un sistema de evaluación de prompts por tu cuenta. Sólo veo dos escenarios prácticos donde una solución ad hoc puede tener sentido:

• Equipos pequeños o experimentales: Puedes evaluar manualmente, y listo. Una Excel (sí, lo sé, una Excel, pero te hace el trabajo) donde pongas el prompt, para qué te sirvió bien, y que la gente vaya poniendo puntaciones o comentarios.

• Si la empresa necesita trazabilidad, gobernanza y evidencias ante auditoría: la inversión en un framework de evaluación puede tener sentido... a no ser que ya haya una PaaS que te lo dé.

👉🏼 Dicho lo cual, mi recomendación es que utilices un sistema ya existente, idealmente como servicio gestionado, creado por una empresa cuyo negocio sea darte ese servicio de evaluación de prompts.

Empieza con una POC que use herramientas existentes y, si las necesidades de integración, seguridad o escala lo requieren, evolucionar hacia una solución ad hoc que se integre con CI/CD, catálogo interno y procesos de PR.

Antes de reinventar la rueda, vale la pena mirar qué opciones ya existen.

Herramientas existentes en el mercado

Algunas opciones que ya ofrecen capacidades de evaluación, gestión y observabilidad de prompts:

• Amazon Bedrock Prompt Management y Prompt Flows, (cómo no) AWS ha montado un sistema interno de evaluación automática de prompts a escala, basado en el paradigma “LLM-as‑a‑judge”. Este flujo permite definir criterios de evaluación (claridad, completitud, formato, etc.) y ejecutarlos de forma sistemática contra cada variante de prompt antes de pasar a producción

• Promptfoo, un framework para testear y evaluar prompts con viewer y CI integration.

• LangSmith, foco en trazabilidad, pruebas y gestión de prompts dentro del ecosistema LangChain.

• PromptLayer, registry y gestión de prompts con versión y colaboración.

• OpenAI Evals, framework para evaluar automáticamente prompts y asistentes mediante tests programables. Me consta que algunas empresas han extendido este framework para una solución ad hoc.

A partir de aquí, lo que tienes que hacer es conocer las opciones y elegir la que más encaje con tus requisitos de integración, privacidad y coste.

Personalmente, y por los criterios que te acabo de indicar, le tengo echado el ojo a Amazon Bedrock Prompt Management. Ya os contaré cómo sale la cosa.

Una vez elegida la herramienta, lo importante es empezar con algo pequeño y medible.

Siguientes pasos

A mi se me ocurrió lo siguiente, y te lo comparto:

1. Definir objetivos de la POC: métricas clave y 2 dominios de datos prioritarios.

2. Elegir 5–10 prompts representativos y 2 modelos para comparar.

3. Montar la POC con una herramienta existente (en mi caso, la solución de AWS) y ejecutar evaluaciones.

4. Revisar resultados con equipos amigos y decidir si extendemos la solución o desarrollamos una versión ad hoc integrada al catálogo de prompts interno.

Espero que todo esto te pueda servir de ayuda.

Guarda este email, porque si estás usando agentes de IA, tarde o temprano esta información te va a venir bien.

¿Te ha gustado la edición de hoy? Compártela con tus amistades 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

¿Mi objetivo?

Mejorar la interacción con los agentes de IA para asistencia de código cuando trabajamos con ellos, y que generen el código en base a nuestras necesidades.

Teniendo archivos de tipo AGENTS.md para los agentes de IA te ahorrarás idas y venidas interactuando con tu asistente de código a la hora de implementar software.

Idas y venidas significan tiempo, y ahorrar tiempo significa que te ahorrarás tokens, ergo, te ahorrarás dinero.

En el email de hoy os explicaré qué son los AGENTS.md, ya que es una solución relativamente joven, la estructura que deben tener y las buenas prácticas para crear archivos AGENTS.md.

🎁 Pero antes de ir al turrón, tengo un regalo para ti.

Si estás suscrito a esta newsletter antes del ✨27 de octubre✨, recibirás, gratis, un prompt perfectamente depurado para que tu agente de IA favorito te genere esos archivos AGENTS.md directamente. Y en español. Suscribete ahora 👇🏻

Suscríbete ahora

¡El 27 de octubre mando el email con el prompt, no te lo pierdas!

Si conoces a alguien que le pueda interesar el tema de AGENTS.md y el prompt, reenvíale este email o dale al botón de compartir 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

Ahora sí, vamos al turrón.

💡 ¿Qué es y para qué sirve un archivo AGENTS.md?

En una frase: Es el README.md para agentes de IA.

AGENTS.md es un archivo Markdown para a agentes de IA para el código. Su propósito es ofrecer contexto e instrucciones precisas que ayuden a herramientas de inteligencia artificial a entender y trabajar con el código de tus proyectos.

A diferencia del README tradicional (orientado a los desarrolladores o usuarios), AGENTS.md contiene información detallada de compilación, pruebas, estilo y convenciones de código que son clave para que los agentes de IA sigan correctamente tus instrucciones.

GitHub Copilot, Cursor, Windsurf, Claude Code se apoyarán en este archivo a la hora de darte soluciones a las solicitudes que les hagas, de tal forma que se adapten a las necesidades concretas del proyecto.

Solo tienes que crear un archivo llamado AGENTS.md en el directorio raíz del proyecto en el que estás trabajando, y el agente de IA lo encontrará.

Ahora que sabemos lo que son y para qué sirven los archivos AGENTS.md, te voy a mostrar la estructura que me está funcionando bien a día de hoy.

🏛️ Estructura de archivo AGENTS.md

Un archivo AGENTS.md se estructura en diferentes secciones de Markdown. Cada sección de AGENTS.md debe documentar lo esencial que el agente necesita saber. Para mí, esto es:

Visión general

Descripción breve del proyecto y su propósito general. Rol de los agentes de IA en él. Contexto arquitectónico general.

Configuración / Build & Test

Comandos exactos para instalar dependencias, compilar y ejecutar pruebas. Por ejemplo: npm install, npm test, etc. También, aprovecho para indicar los frameworks y tecnologías que utiliza el proyecto.

Estilo de código / Convenciones

Reglas de formato, patrones de diseño y linters. Indicar lenguaje(s) (por ejemplo TypeScript estricto), comillas, longitudes de línea, etc. (por ejemplo “usar comillas simples, no punto y coma, tabuladores en lugar de espacios en blanco” 😱). Aquí aprovecho para explicar los patrones de ingeniería que quiero que se usen, como Arquitectura Hexagonal, DDD, etc.

Testing

Detalles de las pruebas automáticas: cómo ejecutarlas, frameworks usados, cobertura mínima. Comandos precisos de test (en bloques de código) para que el agente los copie.

Flujo de trabajo (Git/PR)

Estrategia de ramas (git), convenciones de mensajes de commit, requisitos para pull requests (p. ej. “todos los Pull Request deben seguir conventional commit y usar el Jira ID, por ejemplo feat(IT-6969): Short and meaningful description of the change”).

Seguridad

Variables de entorno sensibles, claves API, límites de acceso y consideraciones de seguridad. Incluir enlaces a documentación de credenciales.

Dale un intento y cuéntame cómo te ha ido 👇🏻

📥 ¡Te cuento!

Para terminar, vamos con las buenas prácticas.

🎯 Buenas prácticas para archivos AGENTS.md

En base a mi experiencia, te recomiendo 4 puntos a tener en cuenta a la hora de crear archivos AGENTS.md para agentes de IA.

Brevedad y claridad

• Mantén el archivo conciso (idealmente ≲150 líneas) para que el agente no se salga mucho del raíl.

• Usa encabezados Markdown y listas con viñetas para organizar la información.

• Empieza cada sección con un título claro, usando bloques de código para los comandos.

• Evita texto redundante o explicaciones excesivas; incluye solo lo que tu “yo del futuro” (o un agente) realmente necesite.

Comandos precisos

• Escribe los comandos tal como se deben ejecutar.

• Enciéralos en ` para que el agente pueda copiarlos directamente. Por ejemplo, en lugar de escribir “instala dependencias”, especifica `npm install` o similar.

Actualización continua

• Tienes que tratar el AGENTS.md como parte del código, esto es, cada vez que se cambie el proceso de compilación, pruebas o convención de código, o lo que sea, actualiza el archivo en el mismo pull request.

• ¡Ojo!, los revisores de las Pull Requests deben asegurar la calidad de este archivo también.

Fuente de verdad única:

• Evita duplicar información disponible en otros documentos (README, wikis, etc.). En su lugar, mete enlaces a esos recursos. Esto mantiene AGENTS.md enfocado, en el raíl, y reduce el riesgo de inconsistencias.

• Se recomienda dejar solo la información crítica para los agentes, refiriendo a documentos técnicos o de proyecto existentes cuando sea necesario

Algo importante una vez tengas el AGENTS.md a disposición del agente de IA.

Al solicitar tareas a un agente de IA, como por ejemplo “Escribe una función que haga X”, recuerda que:

1. Entre más precisa sea la información en AGENTS.md sobre el contexto o convenciones del proyecto…

2. Mejor alineados estarán los resultados.

Cuando le escribas al agente de IA, hazlo pensando en las instrucciones que le has redactado en el archivo.

🎁 ¡Que no se te olvide el regalo!

Recuerda, si estás suscrito a esta newsletter antes del ✨27 de octubre✨, recibirás, gratis, un prompt perfectamente depurado para que tu agente de IA favorito te genere esos archivos AGENTS.md directamente. Y en español. Suscribete ahora 👇🏻

Suscríbete ahora

¡El 27 de octubre mando el email, no te lo pierdas!

Si conoces a alguien que le pueda interesar el tema de AGENTS.md y el prompt, reenvíale este email o dale al botón de compartir 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

¡Nos vemos en la siguiente!

Es lo que destila el equipo de Atlassian en su “The State of Developer Experience in 2025“, a partir del informe de la encuesta de IDC.

¿Cómo se te queda el cuerpo?, ¿Encaja ese dato en la realidad de día a día como desarrollador de software?

Del informe de Atlassian, se leen otros datos muy interesantes, como por ejemplo las horas a la semana que los desarrolladores ahorramos en tareas manuales gracias a las herramientas de IA. El 46% ahorra entre 11 y 20 horas a la semana en tareas manuales… no está mal.

El informe también indica la lista de tareas, no relacionadas con escribir código, para las que los desarrolladores usamos IA (en orden).

1. Buscar y encontrar información.

2. Testing.

3. Redactar y mejorar la documentación.

4. Automatizar los flujos de trabajo.

5. Chatear o interactuar con IA.

Personalmente, no estoy de acuerdo con la número 2, testing, ya que pienso que los tests para código no debería hacerlos la IA, sino nosotros los desarrolladores. No obstante, ”testing” también se puede referir a hacer scripts para hacer pruebas de concepto o pequeñas pruebas, para lo que en este caso estoy de acuerdo en usar IA.

Hasta aquí tenemos 2 puntos importantes:

1. Sólo dedicamos el 16% de nuestro tiempo a programar.

2. Y vemos que, de ese otro 84% de tiempo, podemos reducir un montón de horas gracias a la IA.

Si a eso le juntamos el hecho que, como desarrolladores de software, nos gusta programar, creo que podemos llegar a una interesante conclusión que te puedes llevar en el día de hoy para nuestro viaje a AI Native.

Usa la IA para todas las tareas que te quitan de hacer lo que te gusta: programar

Seguro que la IA disfruta haciendo por nosotros:

• Documentación.

• Tickets de Jira.

• Meeting notes.

• Emails para enviar a management.

• (dí la siguiente).

Y así poder dedicar más de ese 20% de nuestro tiempo a programar.

¿Te ha gustado la edición de hoy? Compártela con tus amistades 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

Ostras… ¡la cantidad de tiempo que me va a ahorrar este chisme a la hora de programar sobre Kafka!

Pero, como todo en la vida, vamos aprendiendo, y en cierto momento me dije:

Pero si a mí lo que me gusta es programar sobre Kafka… por qué voy a usar este agente para que me haga el trabajo que a mi me gusta hacer.

Pero eso soy yo, ¿en tu caso?

Este es el aprendizaje que os traigo hoy, para seguir en nuestro viaje hacia AI Native:

1. Tú, programa los tests de aceptación…

2. Pídele al agente de IA que haga la implementación que satisfaga tus tests…

3. Revisa el código generado por el agente, e itera.

¿Te gusta la edición de hoy? Compártela con tus amistades 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

Sí, lo sé. Hay mucha gente que le gusta programar pero no le gusta programar los tests. No sé si voy a poder convencer a esas personas, pero lo que sí puedo decir por experiencia es que: Empezar por los tests, mejora la calidad de tu software.

Y cuando empezamos a programar desde los tests, estamos hablando de Test Driven Development (de ahora en adelante TDD), cuyos beneficios os cuento un poco más abajo.

Por mi experiencia, usando agentes como Claude Sonnet 4 puedes conseguir tener el 75% del código que puede considerarse mergeable en Git, lo cual diría que está muy bien. Pero, en el porcentaje restante está la diferencia.

No confíes en la IA, ya que escribirá código “lo mejor que pueda” en base a lo que haya asimilado de tus instrucciones: Siempre revisa el código que te da la IA y adáptalo según las necesidades. Sostengo mi afirmación, no solo por propia experiencia, sino por la de los demás, como puedes ver esta gráfica estraída del State Of Devops 2024. Y cito:

Las percepciones de los participantes sobre la fiabilidad del código generado por IA utilizado en el desarrollo fueron complejas.Si bien la gran mayoría de los encuestados (87,9 %) declaró cierto nivel de confianza en la calidad del código generado por IA, el grado de confianza en la calidad del código generado por IA fue generalmente bajo: el 39,2 % declaró poca (27,3 %) o ninguna (11,9 %).

Pero algunas personas os podéis estar preguntando:

Marcos, ¿Pero por qué empezar por los tests cuando puedo trabajar con la IA hasta que me dé tanto el código como los tests?

Pues en esto, tengo 2 razones muy claras:

1. Nosotros, como desarrolladores del software, somos los dueños del “qué debe hacer”. Hemos conseguido descifrar las especificaciones que nos ha dado el equipo de Producto y sabemos exactamente lo que nuestra aplicación debe hacer.

La forma de implementar el código para solucionar un problema puede ser distinta; cada uno de nosotros puede entender unas cosas u otras a partir de las especificaciones… y la IA no va a ser menos.

Tú eres el responsable de cómo la aplicación o la funcionalidad debe responder, por lo tanto tú tienes que escribir los tests de aceptación necesarios para asegurarte de ello. Con esto, le estas poniendo los railes para que la IA implemente el código adecuado cuando se lo pidas.

2. Usar TDD tiene muchos beneficios para nuestros software, nos guste o no. No es mi objetivo citar todos los beneficios de TDD aquí, pero puedo enumerar algunas a partir de diversas publicaciones de Dave Farley sobre el tema:

• Menos bugs.

• Código flexible.

• Mejor diseño.

Recuerda el flujo:

1. Tú, programa los tests de aceptación…

2. Pídele al agente de IA que haga la implementación que satisfaga tus tests…

3. Revisa el código generado por el agente, e itera.

¿Qué opinas de este flujo?, ¿me cuentas qué tal te ha ido? Si te animas a contarme cómo te fue la experiencia, mándame un email a hola@ainative.es o pulsando en este enlace 👇🏻

📥 ¡Te cuento!

¿Cúanto de nuestro código está hecho con IA?

Puede que incluso tu CEO te haya hecho esa pregunta. En mi opinión, no es la pregunta a resolver, por lo menos al inicio.

Mientras esa pregunta se centra en métricas de uso, nuestra verdadera preocupación debería ser redefinir procesos y cultura interna.

Yo pregunto:

¿A qué nos referimos concretamente con AI Native?

Esta fue la primera pregunta que me vino a la cabeza cuando escuché por primera vez que una empresa de tecnología debía conseguir dicho objetivo en los próximos años.

☝🏼 Y esto es lo que quiero tratar de definir en esta primera edición de la newsletter.

La primera respuesta fue:

Creo que deberíamos definir una estrategia para convertirnos en una empresa nativa de IA, como hicimos hace unos años para convertirnos en una empresa Cloud Native.

¿Te gusta la edición de hoy? Compártela con tus amistades 👇🏻

💚 WhatsApp

💙 LinkedIn

🩵 BlueSky

🧡 Telegram

☝🏼 Creo que una transformación como esta no se trata solo de usar APIs de IA abiertas ni Cursor/Windsurf para programar.

👉🏼 Se trata de cambiar la forma en que trabajamos a nivel organizacional y poner al ser humano en el centro del proceso.

Además, creo que este cambio no se limita solo a organizaciones de ingeniería, sino a todos los departamentos de una empresa o StartUp.

☁️ → 🤖 De Cloud Native a AI Native

Hace unos años aprendimos a ser Cloud Native adoptando arquitecturas y prácticas concretas. Varios de esos principios se pueden adaptar al mundo de la IA:

1. Infraestructura como código → Modelos como código

   • Versiona tus modelos con herramientas de MLflow o DVC.

2. Microservicios y API first → Servicios de inferencia API first

   • Diseña endpoints REST/GRPC para invocar modelos desde cualquier equipo.

3. Auto‑escalado y resiliencia → Auto‑escalado de endpoints de IA

   • Configura clusters de inferencia que crezcan bajo demanda.

Lo sé, son 3 pasos que suenan a mucho y aún no sabemos como llegar a eso. Poco a poco. De momento, una analogía práctica:

• Antes, guardabas tu Excel en un disco o USB drive.

• Luego la migraste a la nube y tu Excel vivía en una carpeta compartida.

• Ahora imagina ese mismo fichero “viviendo” en un servicio de IA.

🏩 Una plataforma de IA para toda la empresa

No se trata solo de exponer APIs de IA a Ingeniería.

Se trata de convertir cada departamento en consumidor y prosumidor (bonito palabro) de IA. Algunos ejemplos que veo venir son:

• Ventas: prompts compartidos para escribir emails, calificar leads y hacer demos más eficaces.

• Producto: uso de Figma AI + Jira AI + Confluence AI para elaborar requisitos claros y exportarlos automáticamente a tickets.

• Legal / Finanzas / RR. HH.: asistentes de IA que revisan contratos, analizan presupuestos y automatizan respuestas a FAQs internas.

☝🏼 Estamos empezando.

Aún estamos lejos de lograrlo y tendremos que hacer algunos cambios antes incluso de comenzar la transición a la IA Nativa (como hicimos durante la transición a la Nube Nativa), como ser API first en todos los ámbitos.

Pensando de esta forma, creo que tu empresa puede alcanzar algunos objetivos importantes a medida que transite a AI Native. Te los menciono y te aporto pruebas de que no es humo.

Mejora de la productividad al evitar reinventar prompts y pipelines.

• Zhang et al. (2023) analizan datos de más de 1.200 empresas manufactureras en China y muestran que cada 1 % de aumento de la penetración de IA conduce a un 14,2 % de incremento en la Productividad Total de los Factores (TFP). Este efecto se mantiene tras controles de endogeneidad y pruebas de robustez, y se explica por mejoras en valor añadido, sesgo hacia trabajo cualificado y actualización tecnológica MDPI.

• Li & Wang (2023), usando datos de compañías chinas cotizadas, confirman que la innovación tecnológica en IA aumenta la TFP, principalmente a través de reducción de costes, mayor uso de mano de obra cualificada, digitalización y eficiencia en I+D ScienceDirect.

En China van a tope; Nada nuevo bajo el sol.

Impulso de la experimentación con un feedback loop rápido.

• Koch et al. (2022), con datos de la Encuesta de Innovación Comunitaria en Alemania (CIS 2018), encuentran que las empresas que usan IA alcanzan ventas de innovaciones de “primera mundial” por valor de €16 000 M, y obtienen un 6 % de ahorro de costes en innovación de procesos. Además, aplicar distintos métodos de IA en varias áreas aumenta aún más los resultados innovadores ScienceDirect.

• Müller & Bley (2022) estudian 956 artículos de prensa y concluyen que el 64 % de las implementaciones de IA en I+D se orientan a exploración (nuevos mercados), frente a solo un 5 % para explotación, y que la IA suele aumentar las tareas humanas en lugar de automatizarlas, favoreciendo ciclos de prueba‑error rápidos ScienceDirect.

Atracción de inversores mostrando una plataforma interna madura de IA. Esto es un hecho: las empresas que antes se meten en el mundo IA obtiene más dinero de los inversores.

• Goldfarb et al. (2022) analizan el efecto de la “intensidad de adopción de IA” sobre el crecimiento de ingresos: solo los niveles altos de adopción muestran incrementos significativos de facturación, especialmente cuando van acompañados de inversiones complementarias (cloud, bases de datos) y una estrategia de I+D interna. Ese mayor crecimiento hace que las empresas sean más atractivas para los inversores institucionales ScienceDirect.

• Maarouf et al. (2024) desarrollan un modelo de lenguaje grande (LLM) para predecir el éxito de startups basándose en descripciones de Crunchbase, logrando identificar con alta precisión qué proyectos obtendrán financiación. Esto demuestra que la IA no solo impulsa el negocio, sino que también se integra en el propio proceso de decisión de inversión arXiv.

¿Cómo lo ves?

⚙️ Vamos a lo tangible

Y como no quiero quedarme solo en el discurso fancy, te propongo algunas acciones para que consideres tomar este año. Cosas pequeñas (?), pero que creo que pueden ir sentando las bases de algo más grande.

• Crear un repositorio de prompts

  1. Elige una herramienta de versionado (GitHub/GitLab).

  2. Define una plantilla de prompt (contexto, ejemplo de input/output, etiquetas).

  3. Acordad un flujo de revisión: autor → revisor técnico → publicación.

• Proteger datos sensibles (PII)

  1. Identifica campos críticos en tu(s) base(s) de datos.

  2. Implementa un wrapper/proxy al que tus servicios llamen, en lugar de exponer AWS Bedrock (por ejemplo) directamente, para interactuar con los LLM.

  3. Automatiza tests de seguridad para asegurarte de que nunca se filtran datos.

• Adoptar Model Context Protocol (MCP)

  1. Empieza con un caso de uso no crítico (p. ej., análisis de tickets de soporte).

  2. Mide latencia y costes, ajusta y escala progresivamente hacia casos más estratégicos.

  3. AWS lo está haciendo, ¿será por algo?

¿Aguna otra que hayas implementado ya? Si te animas a contarme cómo te fue la experiencia, mándame un email a hola@ainative.es o pulsando en este enlace 👇🏻

📥 Te cuento!

Quiero empezar dando las gracias a todas las personas que me habéis hecho llegar vuestro apoyo en esta nuevo proyecto. Sin haber publicado aún nada, ya sois muchas y muchos inscritos en esta newsletter y, por ello, os estoy muy agradecido.

Soy Marcos F. Lobo y después de más de 20 años desarrollando software y de haber transformado una Startup en una plataforma SaaS Cloud Native, hoy estoy embarcado en la evolución hacia AI Native… que es justo el reto que esta newsletter viene a resolver.

¿Soy un experto nativo en IA?

Por supuesto que no.

¿Voy a aprender todo lo que pueda y a contártelo para que puedas repetirlo?

Por supuesto que sí.

Cada 2 semanas, encontrarás:

1. Patrones de arquitectura: Transformaciones concretas de tu arquitectura para llegar a funcionar como AI Native, cambios en el desarrollo de software, y las estrategias y cambios culturales necesarios para llegar a AI Native.

2. Soluciones de la vida real: Implementaciones prácticas y probadas en producción que podrás integrar directamente en tu entorno.

3. Historias de éxito locales e internacionales: Descubrirás cómo Startups en España, USA, Inglaterra, Francia, aprovecharon IA para dar un salto cualitativo en las soluciones que ofrecen a sus clientes.

Si tu misión es llevar tu producto SaaS al mundo AI Native, Brújula AI Native te dará las coordenadas exactas.

¿Y qué te espera en la primera edición? Pues os contaré en qué consiste la idea de AI Native y os propondré los primeros pasos para empezar.

Suscríbete ahora y recibe tu primer número el 1 de septiembre de 2025 👇🏻

Suscríbete ahora

Me complace anunciar que Brújula AI Native arranca en septiembre.

Si ya has llevado tu plataforma a Cloud Native y tu siguiente paso es llegar a AI Native, esta newsletter es tu brújula.

En septiembre te traeré:

• Mejores prácticas de arquitectura y cambios en los procedimientos para cumplir con las expectativas de AI Native.

• Cómo transformar sus servicios, sistemas y organización para convertirse en AI Native.

• Casos reales que resuelven dolores, donde descubrirás cómo CTOs y directores de ingeniería en startups SaaS convirtieron el “¿cómo ponemos IA en esto?” en funcionalidades que enamoran a sus usuarios.

Brújula AI Native está aquí para que transformes tu plataforma SaaS a una plataforma AI Native.

¡Nos vemos en septiembre!