Hay una persona ahora mismo, en algún lugar, integrando su API. No están en su sitio de documentación. No han abierto su guía de inicio. No han visto su zona de juegos interactiva ni su cuidada barra lateral de navegación.
Están sentados en Claude. O Copiloto. O Cursor. Han tecleado algo como "integrar la API de facturación de Stripe con mi aplicación Next.js utilizando el enrutador de aplicaciones" y han esperado a que les devolviera el código funcional. La IA leyó sus documentos en su nombre. Encontró los puntos finales relevantes, entendió el flujo de autenticación, eligió los métodos SDK correctos y produjo una implementación.
Hace dos semanas, en el Start Summit Hackathon de St. Gallen, vi cómo ocurría esto en tiempo real. Estaba hablando con un grupo de estudiantes de CS y un par de fundadores de startups en fase inicial sobre cómo abordan las nuevas API, y todos y cada uno de ellos describieron el mismo flujo de trabajo: pegar el problema en una IA, obtener código de vuelta, iterar a partir de ahí. Una de las estudiantes se rió cuando le pregunté si había leído los documentos. "¿Por qué iba a hacerlo? Claude los lee por mí".
La persona nunca visitó su sitio. Puede que nunca visiten su sitio. Y así es como se construye cada vez más el software.
El viaje que nadie planeó
Durante mucho tiempo, las relaciones con los desarrolladores siguieron un camino bien entendido. Usted escribía documentación exhaustiva. Publicó guías de inicio rápido. Usted dio charlas en conferencias. Usted mantuvo una presencia en Stack Overflow. Usted hizo que la referencia de su API fuera buscable, sus SDK idiomáticos, sus mensajes de error útiles.
Ese camino suponía que el desarrollador leería su contenido. Navegaría por tu estructura. Seguiría sus pasos.
La encuesta de desarrolladores 2024 de GitHub reveló que el 97% de los desarrolladores empresariales han utilizado herramientas de codificación de IA en algún momento. La encuesta anual de Stack Overflow mostró que el 76% de todos los desarrolladores utilizan o tienen previsto utilizar herramientas de IA, y que el 62% de los profesionales las utilizan activamente en su día a día. Esas cifras ya eran altas y no han hecho más que subir desde entonces.
El nuevo viaje tiene un aspecto diferente. Alguien describe lo que quiere en lenguaje natural. Un asistente de IA lee la documentación, encuentra las secciones relevantes y genera la integración. El constructor revisa el resultado, tal vez refina la solicitud, tal vez pide un seguimiento. Minutos, no horas.
¿El embudo de puesta en marcha que los equipos de DevRel pasaron años perfeccionando? Se está obviando. No porque fuera malo: el punto de entrada simplemente se ha desplazado.
Dos consumidores, un conjunto de documentos
La documentación tiene ahora dos públicos fundamentalmente diferentes.
El primero es el lector humano. Esta persona sigue existiendo. Aparecen para tomar decisiones de arquitectura, depurar casos límite, revisar la conformidad y comprender conceptos. Quieren explicaciones narrativas, material de referencia bien organizado y un razonamiento claro sobre las compensaciones.
El segundo es el intermediario de la IA. Lee su documentación en nombre de un constructor. No le importa su barra lateral. No aprecia su diseño visual. Necesita un contenido estructurado y comprensible para la máquina: un markdown limpio, un formato coherente, especificaciones explícitas sobre las que pueda razonar sin ambigüedades.
Hoy en día, casi todos los sitios de documentación están optimizados exclusivamente para el primer público. El segundo público es ya el consumidor dominante.
Jeremy Howard identificó esta tensión cuando propuso la norma /llms.txt en 2024. Su observación fue precisa: "Los grandes modelos lingüísticos dependen cada vez más de la información de los sitios web, pero se enfrentan a una limitación crítica: las ventanas de contexto son demasiado pequeñas para manejar la mayoría de los sitios web en su totalidad." La propuesta es sencilla. Un archivo markdown curado en /llms.txt que proporcione a los modelos de IA una visión general estructurada de su producto y enlaces a los recursos más importantes. FastHTML, los propios documentos de Anthropic y un directorio creciente de proyectos ya incluyen uno.
Es una convención útil. Pero también es un síntoma de un problema más profundo. El verdadero problema no es el formato. Es que la mayor parte de la documentación nunca se diseñó pensando en el consumo por parte de las máquinas.
El constructor no recorta gastos
Existe la tentación de mirar a la persona que pregunta a Claude en lugar de leer la documentación y concluir que está tomando atajos. Que no entienden realmente lo que ocurre en el código. Que de alguna manera son un tipo de desarrollador inferior.
Ya he tenido esta conversación suficientes veces como para saber que eso suele ser erróneo.
Muchos de estos constructores son ingenieros experimentados que toman decisiones deliberadas sobre la eficiencia. Entienden el código, sólo que no quieren navegar por cuatro páginas de documentación para encontrar las tres líneas que realmente necesitan. Han aprendido que un asistente de IA puede extraer esas líneas más rápido de lo que ellos pueden escanearlas, así que delegan la lectura. (Sinceramente, yo mismo hago esto. No recuerdo la última vez que leí una guía de inicio de arriba abajo).
Anthropic reconoció este patrón cuando construyó el Protocolo de Contexto Modelo. El MCP está ahora soportado por Claude, ChatGPT, VS Code, Cursor y otros. Está diseñado explícitamente para que los asistentes de IA puedan llegar a sistemas externos, extraer contexto y actuar en consecuencia. La especificación lo describe como un "acceso a un ecosistema de fuentes de datos, herramientas y aplicaciones que aumentarán las capacidades y mejorarán la experiencia del usuario final".
Lea eso con atención: es lenguaje de infraestructura, no de conveniencia. Los constructores que utilizan estas herramientas no están evitando el trabajo. Están trabajando a través de una nueva capa, y su documentación forma parte de esa capa, tanto si usted la diseñó para ello como si no.
Las relaciones entre desarrolladores se construyeron para otra época
Si su estrategia DevRel se diseñó antes de 2023, se diseñó para un mundo en el que los desarrolladores leían directamente la documentación. Ese mundo no ha desaparecido, pero ya no es el patrón de interacción dominante para una parte cada vez mayor de los desarrolladores.
Esto cambia el cálculo de varias actividades de DevRel de larga data.
Conferencias. Una presentación de 45 minutos en una conferencia de desarrolladores llega a una sala de unos cientos de personas. Un archivo /llms.txt bien estructurado y una documentación limpia y legible por máquina llegan a todos los constructores que preguntan a cualquier asistente de IA sobre su producto, continuamente, en cualquier momento. La charla es un acontecimiento único. La documentación legible por máquina se acumula. No digo que las conferencias no tengan valor - literalmente acabo de volver de una - pero la ecuación de apalancamiento ha cambiado.
Guías de inicio. El clásico tutorial de inicio rápido en cinco pasos es cada vez más una formalidad. El constructor no sigue pasos. Describen lo que quieren y esperan que la IA produzca la integración. Si la API está bien documentada en un formato apto para las máquinas, la IA se encarga de la experiencia de puesta en marcha de forma más eficiente de lo que podría hacerlo cualquier tutorial. En su lugar, los tutoriales deberían convertirse en material conceptual: explicar por qué elegir el enfoque A en lugar del B. La IA puede generar la implementación. Es mucho menos fiable a la hora de explicar las compensaciones.
Stack Overflow. Los datos de su propia encuesta muestran que el 84% de los desarrolladores utilizan la documentación técnica directamente, y el 90% de ellos confían en la documentación de los paquetes de API y SDK. Pero la forma en que acceden a esos documentos es cada vez más a través de una capa de IA, no de una pestaña del navegador. Las preguntas que siguen llegando a Stack Overflow tienden a ser las difíciles: casos límite, depuración de producción, cosas que requieren matices. Valiosas, seguro. Pero ya no es donde está el volumen.
Cuando la IA lee sus documentos, la frescura se vuelve crítica
Esta es la parte en la que la mayoría de los equipos no han pensado.
Cuando un humano lee una página de documentación, puede aplicar su juicio. Pueden notar que las capturas de pantalla parecen antiguas, o que un comentario al final dice que el proceso ha cambiado. Pueden entrecerrar los ojos y pensar "esto parece anticuado".
Un asistente de IA no puede hacer nada de eso. Lee el texto, lo procesa como un hecho y genera una respuesta con total confianza. Si la documentación describe un punto final obsoleto, la IA recomendará alegremente integrarse con él. Si la documentación hace referencia a una infraestructura que fue sustituida hace seis meses, la IA describirá la antigua configuración como actual. Sin titubeos.
El constructor confía en la IA. La IA confía en la documentación. Si la documentación está obsoleta, esa cadena de confianza ofrece una respuesta errónea con toda seguridad.
Esto siempre ha sido un problema, obviamente. El contenido obsoleto siempre ha confundido a la gente. Pero el daño se contenía porque los lectores humanos a veces podían detectarlo. Los intermediarios de la IA no pueden. Amplifican el contenido rancio sirviéndolo a escala, con autoridad, a personas que no tienen motivos para dudar de él.
La frescura ya no es una cuestión de calidad del contenido. Es una cuestión de fiabilidad para cada flujo de trabajo impulsado por IA que toque sus documentos.
La palabra "desarrollador" es demasiado estrecha
Las personas que construyan software en 2026 no se identificarán todas como desarrolladores. Algunos son diseñadores que incitan a Claude a construir un prototipo funcional. Algunos son jefes de producto que utilizan Cursor para enviar herramientas internas. Algunos son analistas de datos que describen una canalización de datos en lenguaje natural y dejan que un agente la ensamble. En la Cumbre Start, la mitad de los equipos del hackathon contaban con miembros sin conocimientos de programación que, al final del fin de semana, ya estaban distribuyendo software operativo.
Ramp es un ejemplo útil. Esta empresa de tecnología financiera pasó de una valoración de 5.800 millones de dólares en 2023 a 32.000 millones de dólares a finales de 2025, superando los 1.000 millones de dólares de ingresos anualizados por el camino. Es una de las startups de más rápido crecimiento de la historia. Una parte muy discutida de su enfoque: los jefes de producto construyen características directamente con herramientas de IA en lugar de esperar en un backlog de ingeniería. Los PM de Ramp no se limitan a escribir especificaciones. Envían código. La IA se encarga de la implementación. El PM se encarga de la intención.
No es un atajo. Un nuevo modelo operativo - y está funcionando a una escala que hace realmente difícil descartarlo como un experimento.
Anthropic ha sido deliberado a la hora de llamar a esto la persona "constructora". Sus herramientas están diseñadas no sólo para ingenieros de software profesionales, sino para cualquiera que pueda describir lo que quiere construir. Cuando Claude puede crear una aplicación completa a partir de un diseño Figma mediante MCP, la línea tradicional entre "desarrollador" y "no desarrollador" se disuelve.
Esto tiene implicaciones reales para cualquiera que mantenga documentación o se preocupe por la experiencia de los desarrolladores. Su público ya no se limita a las personas que saben lo que es un punto final REST. Incluye a cualquiera cuyo asistente de IA pueda interactuar con su producto. ¿El PM de Ramp que lanza una función utilizando su API? Probablemente nunca lea directamente su documentación. Su agente de IA sí que lo hará.
Lo que esto significa para la documentación
Si la documentación sirve ahora a dos públicos -lectores humanos e intermediarios de la IA-, tiene que funcionar para ambos. Suena obvio. En la práctica, casi nadie lo hace.
Esto es lo que creo que realmente importa:
**Si la documentación de su API es una bonita página HTML que un LLM tiene que raspar y analizar, la IA está trabajando más de lo que debería. Envíe la especificación OpenAPI sin procesar junto con la versión renderizada. Envíe un markdown limpio. Haga que las especificaciones sean accesibles sin necesidad de que la IA interprete el diseño de la página.
Estructura a nivel de bloque en lugar de narrativa a nivel de página. Los asistentes de IA no consumen la documentación página por página. Extraen las secciones relevantes. Un documento con encabezados claros, párrafos autocontenidos y una semántica explícita a nivel de bloque es mucho más útil para una IA que una narración fluida que requiera leer toda la página para conocer el contexto.
Confíe en las señales de que las máquinas saben leer. ¿Cuándo se revisó este documento por última vez? ¿Sigue siendo actual? ¿Se ha marcado el contenido? Estas señales deben existir de forma que la IA pueda acceder a ellas, no sólo como señales visuales en una página web. Una puntuación de frescura, un estado de caducidad, una fecha de revisión, estos son los metadatos que permiten a una IA decidir si un documento es seguro para utilizarlo como fuente.
La frescura como prerrequisito, no como característica. Cuando un asistente de IA sirve a un constructor una respuesta segura basada en un punto final obsoleto, el daño es peor que un 404. El constructor construye sobre ella. Lo lanza al mercado. Luego se rompe en producción, y nadie sabe por qué hasta que alguien lo rastrea hasta la documentación que debería haber sido actualizada hace meses. Cada documento al que una IA pueda hacer referencia necesita un mecanismo que demuestre que sigue siendo actual. (Este es, con toda franqueza, exactamente el problema que estamos construyendo Rasepi para resolver - caducidad forzada en los bloques de documentación para que el contenido rancio no pueda esconderse).
El silencioso cambio en la forma de representar los productos
Hay una consecuencia más amplia de todo esto que merece la pena exponer directamente.
Su documentación ya no es sólo un manual de referencia para desarrolladores. Es el material de partida que los asistentes de IA utilizan para representar su producto ante el mundo. Cuando un constructor pregunta a Claude cómo utilizar su producto, la respuesta de Claude está moldeada por todo lo que pueda encontrar y analizar de su documentación.
Buena documentación, buena respuesta. Anticuados, ambiguos, encerrados en HTML difícil de parsear para un modelo - peor respuesta, o una incorrecta. Así de sencillo.
La calidad de la respuesta de la IA sobre su producto es ahora un indicador directo de su experiencia como desarrollador. La mayoría de las empresas aún no lo tratan así.
Los equipos que van por delante en esto - Stripe, Vercel, Cloudflare, el propio Anthropic - tratan la legibilidad de la IA como una preocupación de primera clase. Un requisito fundamental que da forma a cómo se escribe, estructura y mantiene la documentación. No es un tema pendiente para el próximo trimestre.
El constructor que está sentado en Claude ahora mismo, describiendo lo que quiere construir, esperando un código de trabajo en cuestión de minutos - puede que nunca vuelva a visitar un sitio de documentación. Pero la IA que les atiende sí lo hará. Constantemente.
Esa IA es ahora su lector más frecuente. La cuestión es si su documentación está preparada para ello.
La mejor estrategia de experiencia del desarrollador en 2026 no es una charla en una conferencia o una guía rápida. Es asegurarse de que la IA lo hace bien.
Este post hace referencia a investigaciones y documentación de productos disponibles públicamente. Las estadísticas se han extraído de GitHub's 2024 developer survey y de Stack Overflow 2024 Developer Survey. La especificación /llms.txt se mantiene en llmstxt.org. El protocolo de contexto de modelo está documentado en modelcontextprotocol.io.