Idea principal

La legibilidad de un repositorio — nomenclatura coherente, estructura explícita, comentarios útiles, historial de merge requests aprovechable — se defendió durante mucho tiempo con un solo argumento: reduce el coste de intervención de los desarrolladores. Es un argumento interno al equipo técnico, y pierde todos los arbitrajes en los que compite con una fecha de entrega.

En cuanto el repositorio sirve para reconstruir una documentación de soporte, un changelog o una especificación, su legibilidad condiciona la calidad de esas salidas. Un código oscuro no produce una documentación oscura: produce una documentación falsa, plausible e indetectable, ya que nadie va a releer la fuente para verificarla.

La limpieza del código se convierte entonces en una variable de producto. Ya no es una comodidad de equipo negociable contra plazo, es la condición de existencia de una familia de artefactos destinados al cliente.

Capa aportada por "Cuatro días de vibe coding…" (2026-07-28). Un segundo uso del repositorio produce el mismo desplazamiento, y es más exigente: cuando la codebase se convierte en el terreno sobre el que un perfil no desarrollador construye con un asistente, su legibilidad decide lo que en ella es factible. Sobre una base con las API internas documentadas, los conceptos de negocio legibles y los componentes estables, un Product Manager compone un módulo o un recorrido con bloques existentes. Sobre una base mal encuadrada, la misma persona y el mismo asistente solo pueden producir un objeto separado, enchufado desde fuera — el apaño no es entonces un defecto de método, es el único régimen que el terreno permite.

Por qué es importante

Esto da a un Product Manager una razón, formulada en sus términos, para defender una inversión de refactoring — hasta ahora defendida únicamente por los desarrolladores y, por tanto, entendida como una preferencia de artesano.

También plantea una condición de entrada honesta: el enfoque que consiste en regenerar los artefactos desde el repositorio no está disponible en todas partes. Sobre una base ilegible, no degrada el resultado, lo vuelve engañoso.

Matices y límites

"Limpio" no tiene una definición oponible. Un repositorio puede estar perfectamente estructurado para un desarrollador y seguir mudo sobre el vocabulario de negocio, que es precisamente lo que una documentación de soporte necesita.

Y la exigencia puede volverse en contra: hacer del repositorio un soporte de generación arriesga a que se escriban en él comentarios destinados a la máquina y no al mantenedor.

Preguntas abiertas

• ¿En qué se reconoce, antes de intentarlo, que una base de código es lo bastante legible como para regenerar de ella artefactos de producto?