Cómo un ex ingeniero de GitHub publicó un libro con 5.500 tests y una tubería CI/CD

Ben Balter, quien trabajó trece años en GitHub antes de partir de la empresa, escribió su libro Open and Async —una guía sobre equipos remotos y distribuidos basada en su experiencia— usando exactamente las mismas herramientas que usa para construir software: Git, Markdown, una tubería de integración continua y más de cinco mil pruebas automatizadas. El resultado: un libro de 100.000 palabras, 576 páginas y cinco formatos publicados (EPUB, Kindle, papel en dos variantes y web), construido desde un solo repositorio de código.

Esto no es solo una anécdota curiosa. Es la prueba de que los flujos de trabajo de desarrollo de software pueden trasladarse a la producción de contenido con resultados medibles —y que el costo marginal de agregar una verificación más es mínimo cuando ya tienes la infraestructura armada.

¿Qué tan "sobreingeniería" llegó este flujo de trabajo?

El punto de partida fue simple: todo el contenido vive como archivos Markdown en un repositorio Git, con cada capítulo en su propio archivo y un index.yml que define el orden. Pero donde la cosa se vuelve notable es en la capa de validación.

Balter configuró seis linters de prosa que corren en tiempo real dentro de VS Code:

• Markdownlint — consistencia de sintaxis
• Harper — gramática y elección de palabras (ejecutado localmente)
• LanguageTool — gramática, puntuación y estilo
• Vale — reglas propias de estilo y términos prohibidos
• Alex — lenguaje excluyente o insensible
• Write-good — voz pasiva, clichés y frases débiles

Cada uno de estos también corre en CI, junto con un conjunto personalizado de pruebas desarrollado por él mismo: scripts de Node, suites Vitest y especificaciones Playwright. En total, alrededor de 70 archivos de prueba con 2.204 casos y aproximadamente 5.500 assertions automatizadas, más otros 1.600 chequeos estructurales por capítulo.

Uno de sus validadores personalizados es particularmente ilustrativo del enfoque: validateGitHubTense, que falla la compilación si alguna oración implica que aún trabaja en GitHub. Lo hizo porque cometió ese error una vez; ahora nunca más lo hará manualmente.

Las tres capas de detección de redundancia

Lo más interesante del sistema no son los linters —esos son estándar— sino la arquitectura de auditorías semánticas que Balter construyó para detectar repetición entre capítulos. Después de releer el manuscrito hasta quedar ciego, necesitaba prueba, no intuición.

Implementó tres capas escalonadas:

1. jscpd — Detección token-level de copiar-pegar. Atrapa bloques literales idénticos entre capítulos, pero nada más sutil.
2. N-gram — Tokeniza cada capítulo, construye n-grams de palabras y marca frases que aparecen en más de un capítulo. Tiene modo cross-chapter e intra-chapter.
3. Semántico — La capa que las anteriores no podían hacer: usa LLMs para detectar el mismo argumento expresado con palabras distintas. Corre en tres passes (intra-capítulo, cross-capítulos vía TL;DR, y clustering de argumentos centrales).

El resultado: las dos primeras capas mecánicas quedaron limpias, pero la auditoría semántica encontró que había hecho el mismo argumento —que trabajar online no es lo mismo que ser remote-first— en cinco capítulos separados, además de 166 auto-reiteraciones menores distribuidas en 51 capítulos.

De Markdown a cinco formatos publishable

Aquí está la parte que tiene implicaciones directas para cualquier equipo que produzca contenido técnico: un único stylesheet de Tailwind CSS compila a través de PostCSS, y cada formato toma una porción diferente:

• Pandoc convierte Markdown a AST (abstract syntax tree), que luego se transforma con filtros Lua para ajustes específicos por formato.
• WeasyPrint dibuja el PDF de impresión usando el mismo box model CSS que usarías para una página web.
• Ghostscript convierte el PDF a PDF/X-1a:2001 —el estándar CMYK que IngramSpark exige para impresión bajo demanda.
• EPUBCheck y Ace by DAISY validan cada EPUB contra los mismos estándares que usan las tiendas al momento del upload.

Todo esto corre en paralelo: 14 trabajos de CI se ejecutan con cada push a main, construyendo y validando cada formato simultáneamente. Un check verde significa que todos los formatos están listos; una X roja alerta antes de que alguien suba algo roto.

La publicación final, sin embargo, sigue siendo manual: Balter sube cada archivo a los dashboards web de Amazon KDP, IngramSpark y Draft2Digital, reingresando metadata en formularios distintos. Su solución parcial: toda la metadata (descripción, categorías BISAC, keywords) vive versionada en el repositorio, y genera un feed ONIX para los canales que lo aceptan.

Qué significa esto para tu startup

No necesitas escribir 5.500 tests para tu documentación interna ni para tus whitepapers. Pero sí hay principios transferibles que cualquier founder puede aplicar hoy:

1. Tu contenido es código fuente. Tratar documentos como artefactos versionados elimina el problema clásico de los "finalv3revisedACTUALLYFINAL.docx". Si estás produciendo contenido técnico, guías o documentación para tu producto, Git + Markdown te da historial completo de cambios, capacidad de revertir errores y reproducibilidad instantánea. No es necesario complicarlo desde el día uno: instala Pandoc, crea un repo, escribe un capítulo en Markdown y haz pandoc chapter.md -o output.pdf. Eso ya es mejor que lo que tienes.

2. Automatiza lo que se repite. El ROI de automatizar la publicación multi-formato aparece cuando necesitas regenerar un documento —ya sea para corregir un error, actualizar precios o traducir contenido. Balter ya tiene pipelines de traducción (portugués brasileño, español latino, alemán) que draftean, fijan IDs de encabezados, aplican glosarios y hacen back-translation para verificar consistencia. Si tu equipo produce contenido bilingüe o multilingüe, esa misma lógica aplica: estructura el contenido como datos, no como texto plano.

3. Los linters no escriben por ti, pero detectan patrones ciegos. Uno de los validadores de Balter (validateHypotheticalHooks) marcó la apertura de un párrafo que él mismo había escrito —sonaba "ghost-authored" porque había absorbido cadencias de texto generado por IA sin darse cuenta. Esto es relevante para cualquier founder que use LLMs como asistencia de redacción: un linter no juzga calidad, pero sí identifica patrones automáticos que tu ojo normalizado ignora.

4. La accesibilidad debe ser gate obligatorio, no opcional. Balter corre axe-core contra WCAG 2.1 AA en light y dark mode con cada build: contraste de colores, alt text obligatorio, orden lógico de headings, links descriptivos. Si tu startup vende productos digitales, esta misma verificación debería correr contra tu sitio y tu documentación pública. No es compliance —es reducción de riesgo legal y ampliator de audiencia.

El contexto más amplio: el movimiento "Docs as Code"

Lo que hace Balter con su libro es una extensión natural de un movimiento ya establecido en la industria: el "Docs as Code". La autora Anne Gentle popularizó el término con su libro Docs Like Code, y organizaciones como GDST, Red Hat y muchas startups de developer tools ya usan repositorios Git para gestionar documentación técnica con pull requests, CI y templates centralizados.

Un artículo de DEV Community publicado en 2025 documenta un caso muy similar: un ingeniero que construyó una tubería completa de producción de libros con Git + Pandoc + Makefile + GitHub Actions, logrando generar PDFs listos para impresión, ePubs y previews HTML desde un solo comando. El consenso entre quienes adoptan este enfoque es consistente: la curva de aprendizaje inicial es de 20 a 40 horas, pero cada documento posterior se beneficia de la infraestructura ya construida.

El formato Markdown que Balter eligió tiene además una ventaja adicional en 2026: según múltiples fuentes del ecosistema, los LLMs leen y generan Markdown nativamente, y su sintaxis ligera consume menos tokens que HTML o formatos ricos. Lo que empezó como una decisión de colaboración humana resultó ser también eficiente para interacción con IA.

Conclusión

La tesis de Balter es honesta: para la mayoría de los libros, todo esto es desproporcionado. Y eso está bien. El valor no está en replicar su setup exacto —5.500 tests, 14 jobs paralelos, filtros Lua personalizados— sino en adoptar la mentalidad subyacente: tratar el contenido como un producto engineering, con versionamiento, automatización y gates de calidad.

Si tu equipo escribe documentación, whitepapers, guías de producto o cualquier contenido técnico recurrentemente, empezar con Markdown + Git + un build script básico de Pandoc ya te pone por encima del 90% de las organizaciones que todavía manejan versiones en carpetas compartidas. Lo demás es iteración incremental.

Fuentes

• How I Over-Engineered My Book
• I Built a Git-Tracked Book Production Pipeline