Docs-as-Code sin fanatismo
Docs-as-Code no significa obligar a todos los redactores a trabajar en un IDE. El objetivo es combinar texto versionado, edición web, previews, comprobaciones automáticas útiles, revisión humana y publicación predecible.
Tema de portada
La IA aprendió a escribir documentación. ¿Qué debe hacer ahora un redactor técnico?
En tres años, la IA generativa convirtió el primer borrador en una operación barata. La cuestión central ya no es si el modelo puede escribir, sino quién responde por los hechos, la estructura, la revisión, las actualizaciones y la calidad.
Cómo documentar correctamente una API REST
Una buena documentación de API combina contratos legibles por máquina con explicaciones humanas, ejemplos ejecutables y errores explícitos. La documentación REST tiene dos audiencias: máquinas y personas.
¿Qué queda del redactor técnico de 2006?
Las herramientas cambiaron radicalmente, pero el núcleo del oficio sigue reconocible: audiencia, evidencia, estructura, terminología y responsabilidad. En 2006 eran comunes herramientas de edición de escritorio, formatos ofimáticos y sistemas de ayuda mantenidos manualmente.
Práctica
Todos los artículos →- Docs-as-Code sin fanatismoDocs-as-Code · Git · Flujo de trabajo
- Deuda de documentación: cómo encontrar lo que realmente perjudica al usuarioCalidad · Procesos · Arquitectura de la información
- Un mapa de propiedad de la documentación sin burocraciaGobernanza · Procesos · Flujo de trabajo
- Cómo organizar la revisión de documentaciónRevisión · Edición · Calidad
- Arquitectura de información para una documentación que no deja de crecerArquitectura de la información · Modelos de contenido · Procesos
Herramientas
Todos los artículos →CI
Cómo elegir un generador de documentación sin elegir una religión
Sphinx, MkDocs, Astro y otros generadores optimizan modelos de contenido y equipos distintos. Decide por flujo de autoría, extensibilidad, localización y coste de mantenimiento, no por entusiasmo ante una demo. Una demo puede verse excelente y ser incorrecta para tu documentación.
V
Elegir búsqueda para documentación: empieza por los fallos
Una guía práctica y verificable sobre Elegir búsqueda para documentación: empieza por los fallos, pensada para equipos que necesitan mantener la documentación clara y sostenible. Cómo abordar «Elegir búsqueda para documentación: empieza por los fallos» con criterios prácticos, verificables y mantenibles para documentación técnica.
SG
Diagramas como código: cuándo ayudan y cuándo no
Una guía práctica y verificable sobre Diagramas como código: cuándo ayudan y cuándo no, pensada para equipos que necesitan mantener la documentación clara y sostenible. Cómo abordar «Diagramas como código: cuándo ayudan y cuándo no» con criterios prácticos, verificables y mantenibles para documentación técnica.
A
Documentación en CI/CD
Trata la documentación como un artefacto de build: valida estructura, enlaces, ejemplos y reglas antes de publicar. CI no decide si una explicación es útil, pero elimina defectos predecibles antes de gastar atención humana.
Últimos
Del archivo de TechWriters →- Ejemplos de código y tablas accesibles en la documentación técnica2026-08-13 · Estándares
- Usa la IA como editora, no como oráculo2026-08-13 · IA y documentación
- Verifica la documentación asistida por IA antes de publicar errores fluidos2026-08-13 · IA y documentación
- La IA aprendió a escribir documentación. ¿Qué debe hacer ahora un redactor técnico?2026-08-13 · IA y documentación
- Los ejemplos de API deben enseñar un flujo, no decorar la referencia2026-08-13 · API
- Documentación de autenticación que evita tickets de soporte2026-08-13 · API
Profesión
IA y documentación
Estándares
Aprendizaje
TechWriters Research · 005
Todo sobre la documentación de Apple
De las notas de Woz y el paste-up de 1982 a Inside Macintosh, HIG, DocC, Markdown y agentes de Xcode.
Upcoming events
All events →Eventos
2006
Del archivo de TechWriters
Ideas, métodos y debates de generaciones anteriores de redactores técnicos, revisados con el contexto actual.