Nuevos patrones de desarrollo en la era de la IA

xguru · 2025-05-26T11:03:01+09:00

Se está formando una cultura de desarrollo que trata a la IA no como una simple herramienta, sino como una tecnología base Las formas tradicionales de control de versiones, dashboards, plantillas, documentación y gestión de secretos están cambiando para ajustarse a la era de la IA Git ya no se interpreta tanto como un sistema de cambios línea por línea del código, sino como un mecanismo de gestión de estado centrado en prompts y resultados de pruebas Los agentes se convierten en autores y consumidores de código, lo que incrementa la necesidad de rediseñar las propias herramientas Los dashboards y las UI están migrando a interfaces basadas en lenguaje natural, evolucionando hacia formatos usados en conjunto por personas y agentes de IA La documentación está cambiando hacia una base de conocimiento para humanos y para IA, reestructurada en formatos que los agentes puedan entender 1. AI-Native Git: redefinir el control de versiones para agentes de IA Git fue diseñado originalmente para rastrear historiales de cambios a nivel de línea en código escrito directamente por personas Pero en un contexto donde la IA genera y modifica automáticamente gran parte del código, ese nivel de seguimiento detallado pierde importancia Los desarrolladores dejan de enfocarse tanto en los cambios en sí y pasan a centrarse más en si el resultado funciona correctamente (si pasan las pruebas, si opera con normalidad, etc.) Un SHA indica que hubo un cambio, pero no contiene información sobre por qué se hizo ni sobre si el cambio es válido Especialmente en cambios grandes o en código generado automáticamente, los desarrolladores no revisan cada diff de forma individual En un workflow AI-first, la combinación de los siguientes elementos se vuelve una unidad más útil Prompt: la entrada que impulsó la generación de código Test: la prueba para verificar el comportamiento esperado Spec y constraints: requisitos de diseño y restricciones Todos ellos se gestionan y rastrean como un bundle versionable Si esto evoluciona un paso más, en un workflow impulsado por agentes, la Source of Truth puede desplazarse upstream hacia prompts, esquemas de datos, contratos de API e intención arquitectónica Como resultado, el código pasa a verse como un artefacto compilado, tratado no como la fuente, sino como un subproducto de esas entradas Git deja de funcionar como workspace de código y opera como un artifact log quién generó el código, con qué modelo y con qué prompt qué pruebas pasaron y metadatos como qué partes requieren revisión humana El historial de cambios incluye prompts, objetivo, pruebas relacionadas e información del modelo que generó el código Con integración a herramientas de revisión por IA como Diamond, es posible crear flujos de revisión automatizados También se pueden superponer metadatos más ricos, como estructuras que separen el código generado por agentes de las zonas protegidas administradas por humanos Si imaginamos un workflow de AI-Native Git podría aparecer una nueva clase de dashboard de Git donde se vean juntos el prompt, el flujo de cambios derivado de él, los resultados de pruebas, la información de los agentes ejecutados y los datos del bundle 2. Dashboards → Synthesis: evolución hacia interfaces dinámicas basadas en IA Durante años, los dashboards han sido la interfaz principal para interactuar con sistemas complejos como sistemas de observabilidad, herramientas de análisis y consolas cloud (como AWS) Sin embargo, por el exceso de controles, gráficas, pestañas y otros elementos, se ha producido una sobrecarga de UX, y era fácil que el usuario se perdiera entre explorar información y ejecutar acciones Especialmente para no especialistas o en contextos de colaboración entre varios equipos, estos dashboards podían percibirse como herramientas intimidantes e ineficientes Los usuarios saben lo que quieren lograr, pero muchas veces no saben dónde buscar ni qué filtros aplicar La generación más reciente de modelos de IA plantea la posibilidad de resolver este problema Permite reinterpretar el dashboard no como un lienzo fijo, sino como un espacio navegable e interactivo Un LLM puede ayudar al usuario de formas como estas: Ubicar controles: “¿Dónde cambio la configuración de rate limit de esta API?” Resumir e integrar datos: “Resúmeme la tendencia de errores de todos los servicios en el entorno de staging durante las últimas 24 horas” Sugerir insights ocultos: “Con base en mi situación de negocio, recomiéndame qué métricas debería vigilar este trimestre” Hoy ya existen tecnologías como Assistant UI, que permiten que los agentes utilicen componentes de React como si fueran herramientas Así como el contenido se vuelve dinámico y personalizado, la propia UI también se reconfigura según la intención del usuario y evoluciona hacia lo conversacional Los dashboards estáticos pronto podrían verse como algo anticuado Ejemplos: Si el usuario dice “Muéstrame las anomalías ocurridas en Europa el fin de semana pasado”, se pueden entregar automáticamente logs resumidos y tendencias sin manipular filtros manualmente Ante la pregunta “¿Por qué cayó el puntaje de NPS la semana pasada?”, la IA puede presentar análisis de sentimiento de encuestas, correlación con despliegues de producto y un resumen diagnóstico En una visión más amplia, si los agentes se convierten en consumidores de software, el propio concepto de “dashboard” también necesita rediseñarse Por ejemplo, un dashboard puede renderizar vistas optimizadas para Agent Experience ofreciendo una interfaz estructurada y programáticamente accesible para reconocer el estado del sistema, tomar decisiones y actuar Como resultado, podría surgir una estructura de interfaz dual con UI para humanos y UI para agentes Ambas comparten el mismo estado, pero se organizan de forma distinta según cómo se consumen Los agentes reemplazan el papel de las alertas tradicionales, los cron jobs y la automatización basada en condiciones, pero como ejecutores con mucho más contexto y flexibilidad Ejemplo: Antes: if error rate > threshold then send alert Basado en agentes: “La tasa de errores está aumentando. La causa es este servicio, y estos son los componentes afectados y las acciones recomendadas” Así, el dashboard deja de ser solo un lugar para observar y se redefine como un espacio donde personas e IA colaboran, integran información y ejecutan acciones 3. La documentación está evolucionando hacia una combinación de herramienta, índice y base de conocimiento interactiva La forma en que los desarrolladores usan la documentación está cambiando Antes se leía siguiendo el índice o revisando una spec desde el inicio, pero ahora se ha generalizado “hacer primero la pregunta” En lugar de “Voy a estudiar esta spec”, aparece un cambio de mentalidad: “Reorganízame esta información de la forma en que la necesito” Este cambio también impacta la forma misma de la documentación, que evoluciona de HTML o Markdown estático a un sistema de conocimiento interactivo respaldado por índices, embeddings y agentes con reconocimiento de herramientas En este contexto están surgiendo herramientas como Mintlify Mintlify no solo organiza la documentación como una base de datos searchable por significado, sino que también se utiliza como fuente de contexto para agentes en múltiples plataformas Por ejemplo, en AI IDEs, extensiones de VS Code y agentes de terminal, la documentación de Mintlify se usa como material de referencia en tiempo real La razón es que los agentes de generación de código usan documentación actualizada como contexto de trabajo Esto está cambiando incluso el propósito mismo de la documentación La documentación ya no debe diseñarse solo para transmitir información a lectores humanos, sino también como una estructura para consumidores-agente En esta nueva dinámica, la documentación pasa a actuar como un manual de uso para agentes de IA Ya no se trata simplemente de exponer contenido, sino de explicar cómo usar correctamente el sistema 4. De plantillas a generación: vibe coding que reemplaza a create-react-app Antes, al iniciar un proyecto, lo habitual era elegir una plantilla estática como create-react-app, next init o rails new Estas plantillas ofrecían una estructura de app consistente, pero era difícil personalizarlas según la intención del desarrollador o el stack, y había que seguir los valores predeterminados del framework Como resultado, para salirse de la configuración base se necesitaba mucho refactoring manual Ahora este flujo está cambiando con la aparición de plataformas text-to-app como Replit, Same.dev, Loveable, Chef by Convex, Bolt y AI IDEs como Cursor Por ejemplo, si el desarrollador describe algo como “un servidor API en TypeScript con Supabase, Clerk y Stripe”, la IA configura automáticamente un proyecto a medida en cuestión de segundos El starter generado no es una plantilla genérica, sino una estructura optimizada para la intención y el stack del desarrollador Este cambio también está modificando la estructura de distribución del ecosistema Ya no se trata de que unos pocos frameworks ocupen el centro del ecosistema como antes, sino de la expansión de flujos de generación personalizados que combinan diversas herramientas y arquitecturas Lo central pasa de elegir un framework a explicar qué quieres construir Aunque un desarrollador elija la combinación de Next.js y tRPC, y otro Vite y React, ambos pueden generar de inmediato proyectos listos para ejecutarse Por supuesto, los stacks estándar también tienen ventajas: mayor productividad del equipo, mejor onboarding, más facilidad para depurar, etc. Pero refactorizar entre frameworks no es solo un problema técnico, sino que está entrelazado con producto, infraestructura y capacidades organizacionales El punto de inflexión está en que el costo de cambiar de framework ha bajado Los agentes de IA ahora pueden entender la intención del proyecto y realizar refactorizaciones a gran escala de forma semiautomatizada Esto facilita la experimentación y deja más margen para probar distintos stacks o revertir decisiones en etapas tempranas Como resultado, la elección del framework se está volviendo reversible (decision reversible) Ejemplo: empezar con Next.js, luego cambiar a Remix + Vite, y que el agente se encargue de toda la refactorización A medida que disminuye el lock-in de framework, también se pueden probar sin tanta carga stacks opinionated 5. Más allá de .env: gestión de secretos en entornos centrados en agentes Durante décadas, los archivos .env han sido la forma básica de gestionar localmente secretos como API keys, URLs de bases de datos y tokens de servicios Este enfoque es simple, portable y amigable para desarrolladores, pero empieza a generar problemas cuando una AI IDE o un agente escribe código, despliega servicios y coordina entornos Es decir, ya no está claro quién es realmente el dueño del archivo .env Está surgiendo una nueva dirección para resolver este problema Por ejemplo, la especificación más reciente de MCP incluye un framework de autorización basado en OAuth 2.1 Esta estructura apunta a dar a los agentes de IA tokens con alcance limitado (scope-based, revocable tokens) en lugar de secretos sin procesar Ejemplo: en vez de recibir una clave completa de AWS, el agente obtiene una credential temporal que solo permite acciones restringidas, como “subir archivos a S3” Otra tendencia es la aparición de brokers de secretos locales (secret brokers) Se ejecutan localmente o junto a la app, y actúan como servicios intermediarios entre el agente y los secretos sensibles El agente no accede directamente a .env ni hardcodea secretos; cuando solicita una tarea específica, el broker la evalúa en tiempo real y concede permisos Ejemplo: solicitud de “desplegar en staging” o “enviar logs a Sentry” El broker lo procesa just-in-time, y todo acceso puede auditarse Este enfoque cambia el acceso a secretos de un esquema basado en sistema de archivos a un modelo de permisos basado en APIs Como resultado, la gestión de secretos evoluciona desde una configuración con .env hacia una estructura de control de acceso basada en OAuth 6. La accesibilidad como interfaz universal: cómo ven las apps los LLM Últimamente, apps como Granola y Highlight solicitan permisos de accesibilidad en macOS, pero no con el objetivo tradicional de asistir a personas con discapacidad, sino para que agentes de IA puedan observar e interactuar con la UI Esto no parece un hack temporal, sino un anticipo de un cambio de interfaz más profundo Las APIs de accesibilidad se crearon originalmente para mejorar la accesibilidad digital de usuarios con discapacidades visuales o motrices Pero al ampliarlas, pueden funcionar como una capa de interfaz universal para agentes de IA En lugar de hacer clic por coordenadas de píxeles o scrapear el DOM, los agentes pueden observar y actuar sobre la app de forma semántica, del mismo modo que las tecnologías de asistencia interpretan la UI El árbol de accesibilidad ya expone elementos de UI estructurados como botones, títulos y campos de entrada Si además se le añade metadata como intent, role y affordance, los agentes podrían manipular la interfaz con precisión según el objetivo y el contexto Esta dirección podría ampliarse con funciones como: Context extraction: consultar, a través de APIs de accesibilidad/semánticas, qué elementos se ven en pantalla, cuáles son interactuables y qué está haciendo el usuario en ese momento Intentful execution: en vez de conectar manualmente varias llamadas a APIs, declarar un objetivo de alto nivel como “agrega el artículo al carrito y elige el envío más rápido”, y que el backend arme el procedimiento de ejecución Fallback UI for LLMs: las funciones de accesibilidad ofrecen una interfaz de respaldo para que los agentes usen apps que no tienen API pública Los desarrolladores pueden definir, además de la UI visual o el DOM, una render surface reconocible por agentes mediante structured annotations o componentes centrados en accesibilidad En resumen, las APIs de accesibilidad están evolucionando hasta convertirse en una capa de interfaz clave para la interacción entre IA, sistemas y apps, no solo para humanos 7. El ascenso del trabajo asíncrono de agentes A medida que los desarrolladores colaboran de forma natural con agentes de escritura de código, se está acelerando la transición hacia flujos de trabajo asíncronos Los agentes ejecutan trabajo en paralelo en segundo plano y reportan resultados cuando alcanzan cierto nivel de avance Esta interacción se parece cada vez menos al pair programming y más a la orquestación de tareas (task orchestration) Es decir, el desarrollador comunica el objetivo, el agente lo ejecuta y luego se revisa más tarde Lo importante no es solo reducir trabajo, sino comprimir la colaboración en sí Por ejemplo, en lugar de pedirle a otro equipo una actualización de archivos de configuración, error triage o refactorización de componentes, el desarrollador puede transmitir directamente su intención al agente y pedirle que lo procese en segundo plano Antes se necesitaban reuniones síncronas, handoffs entre áreas y ciclos largos de revisión, pero ahora el bucle de request → generate → validate ocurre de forma natural También se está expandiendo la forma de interactuar con los agentes Además de simplemente escribir prompts en un IDE o CLI, ahora también es posible hacerlo de las siguientes maneras: Solicitar trabajo por mensaje en Slack Escribir comentarios en un mockup de Figma Dejar comentarios inline en un diff de código o en un PR (ej.: Graphite review assistant) Agregar feedback en una app preview desplegada Explicar verbalmente cambios a través de interfaces de voz o basadas en llamadas Este cambio hace que los agentes estén presentes a lo largo de todo el ciclo de vida de desarrollo Ya no se limitan a escribir código, sino que también interpretan diseños, incorporan feedback y realizan bug triage en toda la plataforma El desarrollador asume el rol de orquestador (orchestrator) que decide qué hilos de trabajo avanzar, descartar o fusionar Esta tendencia sugiere, en última instancia, la posibilidad de que los hilos de trabajo basados en agentes se conviertan en una nueva versión del concepto de “rama de Git” Ya no como forks estáticos de código, sino como hilos dinámicos orientados a objetivos que se ejecutan de forma asíncrona y se integran cuando están listos 8. MCP: Model Context Protocol, un paso más cerca de un estándar universal Desde la publicación reciente de un análisis en profundidad sobre MCP, la velocidad de adopción de MCP se ha acelerado OpenAI adoptó oficialmente MCP, varias funciones nuevas se incorporaron a la especificación, y cada vez más creadores de herramientas están adoptando MCP como la interfaz predeterminada entre los agentes y el mundo real MCP, en esencia, resuelve dos problemas importantes: Proporciona el contexto necesario para que un LLM pueda realizar tareas que encuentra por primera vez Elimina las integraciones personalizadas tipo N×M y simplifica todo a una estructura donde las herramientas exponen una interfaz estándar (servidor) que cualquier agente (cliente) puede usar Se espera que la adopción de MCP siga creciendo, y si aparecen MCP remoto y un registro de MCP de facto (de-facto registry), muchas apps podrían lanzarse con una interfaz MCP incorporada por defecto Así como las APIs en el pasado permitieron conectar herramientas SaaS y construir flujos de trabajo, MCP puede crear un ecosistema de componentes interoperables para agentes de IA Una plataforma con cliente MCP integrado deja de estar simplemente “habilitada para IA” y pasa a ser parte de un ecosistema conectado directamente a una red de capacidades accesibles para agentes Los clientes y servidores de MCP son solo conceptos lógicos; no están separados físicamente Eso significa que cualquier cliente MCP puede ser servidor, y viceversa Esto abre la puerta a una composabilidad de alto nivel, como la siguiente: Ej.: un agente de coding puede, como cliente, traer issues de GitHub y, al mismo tiempo, como servidor, proporcionar a otros agentes cobertura de pruebas o resultados de análisis de código MCP se está consolidando como la capa de interfaz fundamental para un ecosistema en el que herramientas y agentes interactúan de manera orgánica 9. Primitivas abstraídas: autenticación, pagos y almacenamiento que todo agente de IA necesita Cuanto más poderosos se vuelven los agentes de vibe coding, más claro queda un hecho: los agentes pueden generar mucho código, pero necesitan una base confiable a la cual conectar ese código Así como los desarrolladores humanos dependen de Stripe para pagos, Clerk para autenticación y Supabase para base de datos, los agentes también necesitan primitivas de servicio confiables y componibles Estos servicios ofrecen límites claros de API, SDK fáciles de usar y configuraciones predeterminadas razonables, y cada vez más pasan a cumplir el papel de interfaz de runtime para agentes Por ejemplo, al crear una herramienta que genera apps SaaS, en vez de que el agente implemente por sí mismo un sistema de autenticación o lógica de pagos, puede usar Clerk y Stripe para integrarse de forma rápida y segura A medida que este patrón madure, los servicios podrían ir más allá de simplemente ofrecer APIs y exponer también: Schemas: definiciones de datos estructurados Capability metadata: especificaciones de las tareas que pueden realizar Example flows: ejemplos de cómo integrarlos → con ello, los agentes podrían integrarse con mucha más estabilidad Algunos servicios incluso podrían lanzarse con un servidor MCP incorporado Ej.: Clerk podría exponer, a través de un servidor MCP, funciones como consultar la lista de productos disponibles, crear un nuevo plan o modificar suscripciones En lugar de buscar especificaciones de API o documentación, el agente haría la solicitud en lenguaje natural, y el servidor MCP validaría y procesaría la solicitud dentro del alcance de permisos y restricciones Ej.: > “Crea un plan Pro de $49 al mes y configúralo con cargos adicionales por uso” → El servidor MCP de Clerk interpreta y ejecuta esta solicitud Así como rails new permitió desarrollo rápido en los primeros tiempos de la web, en la era de los agentes harán falta primitivas confiables (drop-in identity, pagos, control de acceso, etc.) Deben estar lo suficientemente abstraídas para que los agentes puedan usarlas para generar, pero al mismo tiempo tener una estructura capaz de escalar junto con el crecimiento de la app Conclusión Estos 9 patrones no consisten simplemente en añadir IA a la forma tradicional de desarrollar, sino que muestran que la manera misma de crear software está siendo redefinida en torno a agentes, contexto e intención Como resultado, también están cambiando los patrones de comportamiento de los desarrolladores, y nuevos toolchains y protocolos (como MCP) están surgiendo rápidamente para respaldarlos Capas fundamentales de herramientas existentes como Git, plantillas, dashboards y formas de documentación están siendo rediseñadas de raíz junto con la IA Ante esta transición, se espera que la construcción y la inversión en herramientas e infraestructura de próxima generación que darán forma al nuevo ecosistema de desarrollo se intensifiquen

(a16z.com)

48 puntos por xguru 2025-05-26 | 8 comentarios | Compartir por WhatsApp

Se está formando una cultura de desarrollo que trata a la IA no como una simple herramienta, sino como una tecnología base
Las formas tradicionales de control de versiones, dashboards, plantillas, documentación y gestión de secretos están cambiando para ajustarse a la era de la IA
- Git ya no se interpreta tanto como un sistema de cambios línea por línea del código, sino como un mecanismo de gestión de estado centrado en prompts y resultados de pruebas
- Los agentes se convierten en autores y consumidores de código, lo que incrementa la necesidad de rediseñar las propias herramientas
- Los dashboards y las UI están migrando a interfaces basadas en lenguaje natural, evolucionando hacia formatos usados en conjunto por personas y agentes de IA
- La documentación está cambiando hacia una base de conocimiento para humanos y para IA, reestructurada en formatos que los agentes puedan entender

1. AI-Native Git: redefinir el control de versiones para agentes de IA

Git fue diseñado originalmente para rastrear historiales de cambios a nivel de línea en código escrito directamente por personas
- Pero en un contexto donde la IA genera y modifica automáticamente gran parte del código, ese nivel de seguimiento detallado pierde importancia
- Los desarrolladores dejan de enfocarse tanto en los cambios en sí y pasan a centrarse más en si el resultado funciona correctamente (si pasan las pruebas, si opera con normalidad, etc.)
- Un SHA indica que hubo un cambio, pero no contiene información sobre por qué se hizo ni sobre si el cambio es válido
- Especialmente en cambios grandes o en código generado automáticamente, los desarrolladores no revisan cada diff de forma individual
En un workflow AI-first, la combinación de los siguientes elementos se vuelve una unidad más útil
- Prompt: la entrada que impulsó la generación de código
- Test: la prueba para verificar el comportamiento esperado
- Spec y constraints: requisitos de diseño y restricciones
- Todos ellos se gestionan y rastrean como un bundle versionable
Si esto evoluciona un paso más, en un workflow impulsado por agentes, la Source of Truth puede desplazarse upstream hacia prompts, esquemas de datos, contratos de API e intención arquitectónica
- Como resultado, el código pasa a verse como un artefacto compilado, tratado no como la fuente, sino como un subproducto de esas entradas
- Git deja de funcionar como workspace de código y opera como un artifact log
  - quién generó el código, con qué modelo y con qué prompt
  - qué pruebas pasaron
  - y metadatos como qué partes requieren revisión humana
El historial de cambios incluye prompts, objetivo, pruebas relacionadas e información del modelo que generó el código
- Con integración a herramientas de revisión por IA como Diamond, es posible crear flujos de revisión automatizados
- También se pueden superponer metadatos más ricos, como estructuras que separen el código generado por agentes de las zonas protegidas administradas por humanos
Si imaginamos un workflow de AI-Native Git
- podría aparecer una nueva clase de dashboard de Git donde se vean juntos el prompt, el flujo de cambios derivado de él, los resultados de pruebas, la información de los agentes ejecutados y los datos del bundle

2. Dashboards → Synthesis: evolución hacia interfaces dinámicas basadas en IA

Durante años, los dashboards han sido la interfaz principal para interactuar con sistemas complejos como sistemas de observabilidad, herramientas de análisis y consolas cloud (como AWS)
- Sin embargo, por el exceso de controles, gráficas, pestañas y otros elementos, se ha producido una sobrecarga de UX, y era fácil que el usuario se perdiera entre explorar información y ejecutar acciones
- Especialmente para no especialistas o en contextos de colaboración entre varios equipos, estos dashboards podían percibirse como herramientas intimidantes e ineficientes
- Los usuarios saben lo que quieren lograr, pero muchas veces no saben dónde buscar ni qué filtros aplicar
La generación más reciente de modelos de IA plantea la posibilidad de resolver este problema
- Permite reinterpretar el dashboard no como un lienzo fijo, sino como un espacio navegable e interactivo
Un LLM puede ayudar al usuario de formas como estas:
- Ubicar controles: “¿Dónde cambio la configuración de rate limit de esta API?”
- Resumir e integrar datos: “Resúmeme la tendencia de errores de todos los servicios en el entorno de staging durante las últimas 24 horas”
- Sugerir insights ocultos: “Con base en mi situación de negocio, recomiéndame qué métricas debería vigilar este trimestre”
Hoy ya existen tecnologías como Assistant UI, que permiten que los agentes utilicen componentes de React como si fueran herramientas
- Así como el contenido se vuelve dinámico y personalizado, la propia UI también se reconfigura según la intención del usuario y evoluciona hacia lo conversacional
- Los dashboards estáticos pronto podrían verse como algo anticuado
- Ejemplos:
  - Si el usuario dice “Muéstrame las anomalías ocurridas en Europa el fin de semana pasado”, se pueden entregar automáticamente logs resumidos y tendencias sin manipular filtros manualmente
  - Ante la pregunta “¿Por qué cayó el puntaje de NPS la semana pasada?”, la IA puede presentar análisis de sentimiento de encuestas, correlación con despliegues de producto y un resumen diagnóstico
En una visión más amplia, si los agentes se convierten en consumidores de software, el propio concepto de “dashboard” también necesita rediseñarse
- Por ejemplo, un dashboard puede renderizar vistas optimizadas para Agent Experience
  - ofreciendo una interfaz estructurada y programáticamente accesible para reconocer el estado del sistema, tomar decisiones y actuar
- Como resultado, podría surgir una estructura de interfaz dual con UI para humanos y UI para agentes
  - Ambas comparten el mismo estado, pero se organizan de forma distinta según cómo se consumen
Los agentes reemplazan el papel de las alertas tradicionales, los cron jobs y la automatización basada en condiciones, pero como ejecutores con mucho más contexto y flexibilidad
Ejemplo:
- Antes: if error rate > threshold then send alert
- Basado en agentes: “La tasa de errores está aumentando. La causa es este servicio, y estos son los componentes afectados y las acciones recomendadas”
Así, el dashboard deja de ser solo un lugar para observar y se redefine como un espacio donde personas e IA colaboran, integran información y ejecutan acciones

3. La documentación está evolucionando hacia una combinación de herramienta, índice y base de conocimiento interactiva

La forma en que los desarrolladores usan la documentación está cambiando
- Antes se leía siguiendo el índice o revisando una spec desde el inicio, pero ahora se ha generalizado “hacer primero la pregunta”
- En lugar de “Voy a estudiar esta spec”, aparece un cambio de mentalidad: “Reorganízame esta información de la forma en que la necesito”
- Este cambio también impacta la forma misma de la documentación, que evoluciona de HTML o Markdown estático a un sistema de conocimiento interactivo respaldado por índices, embeddings y agentes con reconocimiento de herramientas
En este contexto están surgiendo herramientas como Mintlify
- Mintlify no solo organiza la documentación como una base de datos searchable por significado, sino que también se utiliza como fuente de contexto para agentes en múltiples plataformas
  - Por ejemplo, en AI IDEs, extensiones de VS Code y agentes de terminal, la documentación de Mintlify se usa como material de referencia en tiempo real
- La razón es que los agentes de generación de código usan documentación actualizada como contexto de trabajo
Esto está cambiando incluso el propósito mismo de la documentación
- La documentación ya no debe diseñarse solo para transmitir información a lectores humanos, sino también como una estructura para consumidores-agente
- En esta nueva dinámica, la documentación pasa a actuar como un manual de uso para agentes de IA
- Ya no se trata simplemente de exponer contenido, sino de explicar cómo usar correctamente el sistema

4. De plantillas a generación: vibe coding que reemplaza a create-react-app

Antes, al iniciar un proyecto, lo habitual era elegir una plantilla estática como create-react-app, next init o rails new
- Estas plantillas ofrecían una estructura de app consistente, pero era difícil personalizarlas según la intención del desarrollador o el stack, y había que seguir los valores predeterminados del framework
- Como resultado, para salirse de la configuración base se necesitaba mucho refactoring manual
Ahora este flujo está cambiando con la aparición de plataformas text-to-app como Replit, Same.dev, Loveable, Chef by Convex, Bolt y AI IDEs como Cursor
- Por ejemplo, si el desarrollador describe algo como “un servidor API en TypeScript con Supabase, Clerk y Stripe”, la IA configura automáticamente un proyecto a medida en cuestión de segundos
- El starter generado no es una plantilla genérica, sino una estructura optimizada para la intención y el stack del desarrollador
Este cambio también está modificando la estructura de distribución del ecosistema
- Ya no se trata de que unos pocos frameworks ocupen el centro del ecosistema como antes, sino de la expansión de flujos de generación personalizados que combinan diversas herramientas y arquitecturas
- Lo central pasa de elegir un framework a explicar qué quieres construir
- Aunque un desarrollador elija la combinación de Next.js y tRPC, y otro Vite y React, ambos pueden generar de inmediato proyectos listos para ejecutarse
Por supuesto, los stacks estándar también tienen ventajas:
- mayor productividad del equipo, mejor onboarding, más facilidad para depurar, etc.
- Pero refactorizar entre frameworks no es solo un problema técnico, sino que está entrelazado con producto, infraestructura y capacidades organizacionales
El punto de inflexión está en que el costo de cambiar de framework ha bajado
- Los agentes de IA ahora pueden entender la intención del proyecto y realizar refactorizaciones a gran escala de forma semiautomatizada
- Esto facilita la experimentación y deja más margen para probar distintos stacks o revertir decisiones en etapas tempranas
Como resultado, la elección del framework se está volviendo reversible (decision reversible)
- Ejemplo: empezar con Next.js, luego cambiar a Remix + Vite, y que el agente se encargue de toda la refactorización
A medida que disminuye el lock-in de framework, también se pueden probar sin tanta carga stacks opinionated

5. Más allá de `.env`: gestión de secretos en entornos centrados en agentes

Durante décadas, los archivos .env han sido la forma básica de gestionar localmente secretos como API keys, URLs de bases de datos y tokens de servicios
- Este enfoque es simple, portable y amigable para desarrolladores, pero empieza a generar problemas cuando una AI IDE o un agente escribe código, despliega servicios y coordina entornos
- Es decir, ya no está claro quién es realmente el dueño del archivo .env
Está surgiendo una nueva dirección para resolver este problema
- Por ejemplo, la especificación más reciente de MCP incluye un framework de autorización basado en OAuth 2.1
- Esta estructura apunta a dar a los agentes de IA tokens con alcance limitado (scope-based, revocable tokens) en lugar de secretos sin procesar
- Ejemplo: en vez de recibir una clave completa de AWS, el agente obtiene una credential temporal que solo permite acciones restringidas, como “subir archivos a S3”
Otra tendencia es la aparición de brokers de secretos locales (secret brokers)
- Se ejecutan localmente o junto a la app, y actúan como servicios intermediarios entre el agente y los secretos sensibles
- El agente no accede directamente a .env ni hardcodea secretos; cuando solicita una tarea específica, el broker la evalúa en tiempo real y concede permisos
  - Ejemplo: solicitud de “desplegar en staging” o “enviar logs a Sentry”
  - El broker lo procesa just-in-time, y todo acceso puede auditarse
Este enfoque cambia el acceso a secretos de un esquema basado en sistema de archivos a un modelo de permisos basado en APIs
- Como resultado, la gestión de secretos evoluciona desde una configuración con .env hacia una estructura de control de acceso basada en OAuth

6. La accesibilidad como interfaz universal: cómo ven las apps los LLM

Últimamente, apps como Granola y Highlight solicitan permisos de accesibilidad en macOS, pero no con el objetivo tradicional de asistir a personas con discapacidad, sino para que agentes de IA puedan observar e interactuar con la UI
- Esto no parece un hack temporal, sino un anticipo de un cambio de interfaz más profundo
Las APIs de accesibilidad se crearon originalmente para mejorar la accesibilidad digital de usuarios con discapacidades visuales o motrices
- Pero al ampliarlas, pueden funcionar como una capa de interfaz universal para agentes de IA
- En lugar de hacer clic por coordenadas de píxeles o scrapear el DOM, los agentes pueden observar y actuar sobre la app de forma semántica, del mismo modo que las tecnologías de asistencia interpretan la UI
- El árbol de accesibilidad ya expone elementos de UI estructurados como botones, títulos y campos de entrada
- Si además se le añade metadata como intent, role y affordance, los agentes podrían manipular la interfaz con precisión según el objetivo y el contexto
Esta dirección podría ampliarse con funciones como:
- Context extraction: consultar, a través de APIs de accesibilidad/semánticas, qué elementos se ven en pantalla, cuáles son interactuables y qué está haciendo el usuario en ese momento
- Intentful execution: en vez de conectar manualmente varias llamadas a APIs, declarar un objetivo de alto nivel como “agrega el artículo al carrito y elige el envío más rápido”, y que el backend arme el procedimiento de ejecución
- Fallback UI for LLMs: las funciones de accesibilidad ofrecen una interfaz de respaldo para que los agentes usen apps que no tienen API pública
  - Los desarrolladores pueden definir, además de la UI visual o el DOM, una render surface reconocible por agentes mediante structured annotations o componentes centrados en accesibilidad
En resumen, las APIs de accesibilidad están evolucionando hasta convertirse en una capa de interfaz clave para la interacción entre IA, sistemas y apps, no solo para humanos

7. El ascenso del trabajo asíncrono de agentes

A medida que los desarrolladores colaboran de forma natural con agentes de escritura de código, se está acelerando la transición hacia flujos de trabajo asíncronos
- Los agentes ejecutan trabajo en paralelo en segundo plano y reportan resultados cuando alcanzan cierto nivel de avance
- Esta interacción se parece cada vez menos al pair programming y más a la orquestación de tareas (task orchestration)
- Es decir, el desarrollador comunica el objetivo, el agente lo ejecuta y luego se revisa más tarde
Lo importante no es solo reducir trabajo, sino comprimir la colaboración en sí
- Por ejemplo, en lugar de pedirle a otro equipo una actualización de archivos de configuración, error triage o refactorización de componentes,
  el desarrollador puede transmitir directamente su intención al agente y pedirle que lo procese en segundo plano
- Antes se necesitaban reuniones síncronas, handoffs entre áreas y ciclos largos de revisión,
  pero ahora el bucle de request → generate → validate ocurre de forma natural
También se está expandiendo la forma de interactuar con los agentes
- Además de simplemente escribir prompts en un IDE o CLI, ahora también es posible hacerlo de las siguientes maneras:
  - Solicitar trabajo por mensaje en Slack
  - Escribir comentarios en un mockup de Figma
  - Dejar comentarios inline en un diff de código o en un PR (ej.: Graphite review assistant)
  - Agregar feedback en una app preview desplegada
  - Explicar verbalmente cambios a través de interfaces de voz o basadas en llamadas
Este cambio hace que los agentes estén presentes a lo largo de todo el ciclo de vida de desarrollo
- Ya no se limitan a escribir código, sino que también interpretan diseños, incorporan feedback y realizan bug triage en toda la plataforma
- El desarrollador asume el rol de orquestador (orchestrator) que decide qué hilos de trabajo avanzar, descartar o fusionar
Esta tendencia sugiere, en última instancia, la posibilidad de que los hilos de trabajo basados en agentes se conviertan en una nueva versión del concepto de “rama de Git”
- Ya no como forks estáticos de código, sino como hilos dinámicos orientados a objetivos que se ejecutan de forma asíncrona y se integran cuando están listos

8. MCP: Model Context Protocol, un paso más cerca de un estándar universal

Desde la publicación reciente de un análisis en profundidad sobre MCP, la velocidad de adopción de MCP se ha acelerado
OpenAI adoptó oficialmente MCP, varias funciones nuevas se incorporaron a la especificación, y
cada vez más creadores de herramientas están adoptando MCP como la interfaz predeterminada entre los agentes y el mundo real
MCP, en esencia, resuelve dos problemas importantes:
- Proporciona el contexto necesario para que un LLM pueda realizar tareas que encuentra por primera vez
- Elimina las integraciones personalizadas tipo N×M y simplifica todo a una estructura donde las herramientas exponen una interfaz estándar (servidor) que cualquier agente (cliente) puede usar
Se espera que la adopción de MCP siga creciendo, y
si aparecen MCP remoto y un registro de MCP de facto (de-facto registry),
muchas apps podrían lanzarse con una interfaz MCP incorporada por defecto
Así como las APIs en el pasado permitieron conectar herramientas SaaS y construir flujos de trabajo,
MCP puede crear un ecosistema de componentes interoperables para agentes de IA
Una plataforma con cliente MCP integrado deja de estar simplemente “habilitada para IA” y pasa a ser
parte de un ecosistema conectado directamente a una red de capacidades accesibles para agentes
Los clientes y servidores de MCP son solo conceptos lógicos; no están separados físicamente
- Eso significa que cualquier cliente MCP puede ser servidor, y viceversa
- Esto abre la puerta a una composabilidad de alto nivel, como la siguiente:
  - Ej.: un agente de coding puede, como cliente, traer issues de GitHub y, al mismo tiempo, como servidor, proporcionar a otros agentes cobertura de pruebas o resultados de análisis de código
MCP se está consolidando como la capa de interfaz fundamental para un ecosistema en el que herramientas y agentes interactúan de manera orgánica

9. Primitivas abstraídas: autenticación, pagos y almacenamiento que todo agente de IA necesita

Cuanto más poderosos se vuelven los agentes de vibe coding, más claro queda un hecho:
los agentes pueden generar mucho código, pero necesitan una base confiable a la cual conectar ese código
Así como los desarrolladores humanos dependen de Stripe para pagos, Clerk para autenticación y Supabase para base de datos,
los agentes también necesitan primitivas de servicio confiables y componibles
Estos servicios ofrecen límites claros de API, SDK fáciles de usar y configuraciones predeterminadas razonables,
y cada vez más pasan a cumplir el papel de interfaz de runtime para agentes
Por ejemplo, al crear una herramienta que genera apps SaaS, en vez de que el agente implemente por sí mismo un sistema de autenticación o lógica de pagos,
puede usar Clerk y Stripe para integrarse de forma rápida y segura
A medida que este patrón madure, los servicios podrían ir más allá de simplemente ofrecer APIs y exponer también:
- Schemas: definiciones de datos estructurados
- Capability metadata: especificaciones de las tareas que pueden realizar
- Example flows: ejemplos de cómo integrarlos
  → con ello, los agentes podrían integrarse con mucha más estabilidad
Algunos servicios incluso podrían lanzarse con un servidor MCP incorporado
- Ej.: Clerk podría exponer, a través de un servidor MCP, funciones como consultar la lista de productos disponibles, crear un nuevo plan o modificar suscripciones
- En lugar de buscar especificaciones de API o documentación, el agente haría la solicitud en lenguaje natural,
  y el servidor MCP validaría y procesaría la solicitud dentro del alcance de permisos y restricciones
- Ej.:
  > “Crea un plan Pro de $49 al mes y configúralo con cargos adicionales por uso”
  → El servidor MCP de Clerk interpreta y ejecuta esta solicitud
Así como rails new permitió desarrollo rápido en los primeros tiempos de la web,
en la era de los agentes harán falta primitivas confiables (drop-in identity, pagos, control de acceso, etc.)
- Deben estar lo suficientemente abstraídas para que los agentes puedan usarlas para generar,
  pero al mismo tiempo tener una estructura capaz de escalar junto con el crecimiento de la app

Conclusión

Estos 9 patrones no consisten simplemente en añadir IA a la forma tradicional de desarrollar, sino que muestran que la manera misma de crear software está siendo redefinida en torno a agentes, contexto e intención
Como resultado, también están cambiando los patrones de comportamiento de los desarrolladores, y nuevos toolchains y protocolos (como MCP) están surgiendo rápidamente para respaldarlos
Capas fundamentales de herramientas existentes como Git, plantillas, dashboards y formas de documentación están siendo rediseñadas de raíz junto con la IA
Ante esta transición, se espera que la construcción y la inversión en herramientas e infraestructura de próxima generación que darán forma al nuevo ecosistema de desarrollo se intensifiquen

8 comentarios

aa1567 2025-05-28

¿De verdad hay gente que hace la opción 1...?

hhcrux 2025-05-27

Los LLM no garantizan la misma salida para la misma entrada, ¿de verdad funciona una gestión de configuración así...?
¿O será que yo todavía los estoy usando de una forma demasiado unidimensional?

beoks 2025-05-27

Entiendo que, si configuras la opción temperature en 0, se garantiza la misma salida para la misma entrada.

fanotify 2025-05-28

De todos modos, dentro de unos meses el modelo en sí volverá a cambiar, así que ¿no sería algo sin sentido?

beoks 2025-05-27

Dejando eso de lado, es demasiado tajante asumir que ni siquiera se contempla la intervención humana,
para cambios simples de cifras o mensajes, probablemente sea más eficiente que intervenga una persona que un LLM.

nicewook 2025-05-26

Es un texto que transmite una gran profundidad. Como era de esperarse de a16z.

ruinnel 2025-05-26

https://es.news.hada.io/topic?id=21091
Después de leer este artículo, no sé si esto tiene sentido.

ahwjdekf 2025-05-26

La número 1 de verdad es un cambio como de pesadilla, uno que nunca querría aceptar. Es como si el rastreo del historial del código fuente perdiera todo sentido.