La IA ha cambiado lo que los ingenieros deben documentar por sí mismos. GitHub Copilot, Cursor y Mintlify pueden generar documentos preliminares: descripciones de parámetros, resúmenes de funciones y plantillas README. Lo que no pueden escribir es la capa de intención: la decisión tomada, la compensación aceptada, la restricción que importaba y la opción que el equipo rechazó.
El código muestra el comportamiento. Rara vez conserva el razonamiento. Ese razonamiento suele encontrarse en un hilo de Slack, en un comentario de un ticket, en la revisión de una incidencia o en la memoria de alguien.
La Encuesta a desarrolladores de 2024 de Stack Overflow reveló que el 61 % de los desarrolladores profesionales dedica más de 30 minutos al día a buscar respuestas en el trabajo, y uno de cada cuatro dedica más de una hora. Por supuesto, algunas búsquedas son inevitables. Pero el verdadero desperdicio es el contexto de los sprints que nunca llegó a plasmarse en un documento.
Esta guía muestra qué deben escribir los propios ingenieros, en qué aspectos puede ayudar la IA y cómo mantener la utilidad de los documentos del código una vez finalizado el sprint.
Resumen
La IA puede redactar la parte mecánica de la documentación: cadenas de documentación, tipos de parámetros, resúmenes de funciones y plantillas de README. Los ingenieros siguen teniendo que redactar la parte relativa a la intención: las decisiones, las compensaciones, las restricciones y las opciones descartadas que hay detrás del código.
Los ingenieros deben seguir redactando eso ellos mismos, en los registros de decisiones de arquitectura, las descripciones de las solicitudes de incorporación de cambios (PR) y los comentarios explicativos que se incluyen junto con el código. La capa de intención evita que el siguiente desarrollador tenga que realizar ingeniería inversa a partir de los nombres de las variables, los mensajes de confirmación y las antiguas solicitudes de incorporación de cambios. La IA ya puede redactar las partes rutinarias: tipos de parámetros, descripciones de retorno y resúmenes básicos de funciones.
¿Qué debería explicar realmente la documentación del código?
La documentación del código debe ayudar al siguiente desarrollador a comprender qué hace el código, cómo utilizarlo de forma segura y por qué se ha creado de esa manera. Aparece en dos lugares: dentro de los archivos fuente, en forma de comentarios y cadenas de documentación, y fuera de los archivos fuente, en forma de archivos README, referencias de API, guías de ejecución y notas de arquitectura.
La mayoría de los códigos se vuelven difíciles de leer cuando desaparece el contexto de la decisión. Es posible que el desarrollador original haya hecho una elección acertada. El desarrollador siguiente solo ve el resultado, no el razonamiento.
El resultado: cada nuevo miembro del equipo tiene que deducir la intención a partir de los nombres de las variables, los mensajes de confirmación y las solicitudes de incorporación de cambios antiguas. Esto ralentiza la incorporación, las revisiones, la depuración y los cambios futuros en esa misma área.
Una buena documentación responde a cuatro preguntas:
- ¿A quién va dirigido este código? A desarrolladores internos, colaboradores de código abierto, usuarios externos de API o usuarios finales.
- ¿Qué problema resuelve? La necesidad empresarial o técnica que subyace al módulo
- ¿Por qué se eligió este enfoque? Las alternativas consideradas y las concesiones aceptadas
- ¿Dónde están los elementos relacionados? Módulos con dependencia, servicios upstream, decisiones de arquitectura, tickets y guías operativas
La pregunta «por qué» es la que merece mayor atención por parte de las personas.
La búsqueda ya supone una carga importante para el trabajo intelectual también fuera del ámbito de la ingeniería. La encuesta sobre gestión del conocimiento de ClickUp reveló que el 57 % de los empleados pierde tiempo buscando información relacionada con el trabajo en documentos internos o bases de conocimiento. Cuando no encuentran lo que necesitan, 1 de cada 6 recurre a soluciones personales: rebuscar entre correos electrónicos antiguos, notas o capturas de pantalla.
La documentación del código falla de la misma manera: si los desarrolladores no pueden encontrar la explicación, es como si esta no existiera.
El coste de equivocarse es elevado. Un usuario de r/AskProgramming describió un flujo de trabajo de RPA en el que un botón no documentado estuvo a punto de ser el desencadenante de cargos bancarios automáticos y cartas personalizadas a los clientes.
La búsqueda ya supone una carga importante para el trabajo intelectual también fuera del ámbito de la ingeniería. La encuesta sobre gestión del conocimiento de ClickUp reveló que el 57 % de los empleados pierde tiempo buscando información relacionada con el trabajo en documentos internos o bases de conocimiento. Cuando no encuentran lo que necesitan, 1 de cada 6 recurre a soluciones personales: rebuscar entre antiguos correos electrónicos, notas o capturas de pantalla.
La documentación del código falla de la misma manera: si los desarrolladores no pueden encontrar la explicación, es como si esta no existiera.
El coste de equivocarse es elevado. Un usuario de r/AskProgramming describió un flujo de trabajo de RPA en el que un botón no documentado estuvo a punto de desencadenar cargos bancarios automáticos y cartas a los clientes.
¿Cuáles son los principales tipos de documentación de código?
Los cinco tipos principales son los comentarios en línea, las cadenas de documentación, los archivos README, los wikis internos y la documentación externa de la API. Cada uno está dirigido a un lector diferente en un momento distinto. Mezclarlos complica la redacción de la documentación y dificulta su uso. Un archivo README que se lee como una cadena de documentación ahuyenta a los nuevos colaboradores. Una cadena de documentación que se lee como una página wiki se convierte en un lastre dentro de los archivos fuente.
Comentarios en línea y cadenas de documentación
Los comentarios en línea deben explicar razonamientos que no sean evidentes. Un comentario que reformule x = x + 1 como «incrementar x» no aporta nada. Un comentario que diga «desplazamiento para la respuesta de la API con índice cero» tiene su razón de ser porque el código no puede mostrar esa restricción externa. Reserva los comentarios en línea para la lógica no evidente dentro del cuerpo de una función.
Las cadenas de documentación (docstrings) son descripciones estructuradas asociadas a funciones, clases o módulos. Abarcan parámetros, valores de retorno, excepciones y ejemplos de uso. Cada lenguaje tiene sus propias convenciones. Sigue la convención que ya espera tu lenguaje: PEP 257 para las cadenas de documentación de Python, Javadoc para Java y JSDoc para JavaScript y TypeScript.
Compara estos dos ejemplos:
Docstring deficiente:
Docstring sólido:
El segundo nombra la función con claridad, documenta sus parámetros y pone de manifiesto una suposición: el flujo de pago utiliza un tipo impositivo del 8,25 %.
README, wikis y documentos externos
Un archivo README debe responder a cinco preguntas en este orden: ¿Qué hace este proyecto? ¿Cómo lo instalo? ¿Cómo lo uso? ¿Cómo puedo contribuir? ¿Dónde puedo obtener ayuda? Si un nuevo colaborador no encuentra rápidamente la ruta de configuración, es que el archivo README está sobrecargado o mal organizado.
Los wikis y las bases de conocimiento funcionan mejor para contenidos que abarcan múltiples repositorios o servicios: decisiones de arquitectura, guías de incorporación y manuales de procedimientos. Un wiki al que nadie enlaza desde el código se convierte en un segundo problema de búsqueda.
La documentación externa abarca referencias de API, guías de SDK y documentos dirigidos a los usuarios. Está pensada para los usuarios de su código, no para los colaboradores. Los documentos externos necesitan más detalles de configuración, pasos de autenticación más claros y una estructura de tipo referencia, ya que es posible que el lector no conozca en absoluto su código base.
Si el equipo aún no tiene una estructura, empieza con una plantilla de documentación técnica para la arquitectura y las notas de configuración, o con una plantilla de documentación del proyecto para las metas, los propietarios, los hitos y las decisiones. Adapta las secciones en lugar de inventar un formato desde cero.
| Tipo | Público principal | Frecuencia de actualización | Ubicación típica |
|---|---|---|---|
| Comentarios en línea | Desarrolladores que leen una ruta de código específica | Cuando cambia el comportamiento del código | Archivos fuente |
| Cadenas de documentación | Desarrolladores que invocan una función, clase o módulo | Cuando cambia la interfaz | Archivos fuente |
| README | Nuevos colaboradores y evaluadores | Por cada lanzamiento importante o cambio en el proyecto | Raíz del repositorio |
| Wiki o base de conocimientos | Equipos internos y partes interesadas de distintos equipos | A medida que cambian las decisiones o los procesos | Wiki del repositorio o base de conocimientos compartida |
| Documentación de API externas | Usuarios de la API y usuarios finales | Por lanzamiento o versión de la API | Plataforma de documentación |
¿Cómo se redacta realmente la documentación hoy en día?
Utilice la IA para las partes que puede redactar. Dedique el tiempo humano a las decisiones, las limitaciones y las compensaciones.
La IA ya puede redactar gran parte del trabajo mecánico: tipos de parámetros, descripciones de retorno y resúmenes básicos de funciones. El trabajo de documentación realizado por personas se divide en dos categorías.
Escribe primero código autodocumentado
La mejor documentación es el código que apenas la necesita. Los nombres descriptivos, las funciones con un único propósito y las convenciones coherentes reducen la carga de documentación antes incluso de escribir un solo comentario.
El código autodocumentado facilita la lectura del comportamiento. Rara vez explica el razonamiento que hay detrás de ese comportamiento. Los nombres ayudan a los desarrolladores a identificar qué hace algo. La documentación debe explicar el razonamiento que los nombres no pueden transmitir.
Antes de añadir un comentario, pregúntate si cambiar el nombre de una variable o extraer una función haría que el comentario fuera innecesario. Si la respuesta es sí, refactoriza primero. Un nombre claro elimina los comentarios que solo sirven para explicar un mal nombre.
Antes:
Después:
La versión refactorizada transmite la misma información solo a través de los nombres. El único comentario útil ahora explicaría por qué se excluyen ciertos roles, lo cual es una decisión de política que el código no puede expresar por sí mismo.
Redacta la capa de intención (la parte que la IA no puede hacer)
La implementación tiene visibilidad en el código. La intención desaparece a menos que alguien la anote. El código rara vez conserva el motivo por el que se hizo una concesión, qué restricción determinó un diseño o qué alternativa se rechazó.
Una regla habitual entre los desarrolladores lo resume bien: documenta el porqué, no el qué. Un comentario muy votado en r/coding:
Veo que esta condición ramifica entre usuarios rojos y azules. Explícame por qué se clasifican así los usuarios y por qué se ramifica entre ellos.
Veo que esta condición ramifica entre usuarios rojos y azules. Explícame por qué se clasifican así los usuarios y por qué se ramifica entre ellos.
Un mensaje de confirmación puede ser útil durante la revisión, pero no es un buen lugar a largo plazo para la justificación del diseño, ya que los futuros lectores rara vez lo encuentran en el momento en que lo necesitan.
Will Larson, antiguo director técnico de Calm y autor de An Elegant Puzzle, ha escrito sobre el valor de los registros de decisiones de arquitectura, ya que conservan la justificación técnica fuera del código fuente.
Los ADR son útiles porque proporcionan un marco estable para la justificación del diseño. Si su equipo no dispone de un formato, utilice una plantilla de ADR sencilla: decisión, contexto, opciones consideradas, compensaciones y consecuencias.
Centra tu documentación en estas categorías:
- Decisiones de diseño y alternativas: «En este caso, hemos optado por una caché de escritura directa en lugar de una de escritura diferida, ya que la coherencia de los datos es más importante que la latencia de escritura para este flujo de pago».
- Limitaciones conocidas: deuda técnica, restricciones de escalabilidad, soluciones provisionales o áreas que requieren una limpieza futura
- Supuestos: Formatos de entrada esperados, requisitos del entorno o dependencias de niveles superiores que el código no impone.
- Referencias: Enlaces a tickets, RFC o registros de decisiones de arquitectura (ADR) relevantes que explican el contexto más amplio
Cada contexto requiere un lugar específico. Las cadenas de documentación (docstrings) recogen la intención a nivel de función. Los comentarios del código abordan el razonamiento a nivel de línea. Las descripciones de las solicitudes de incorporación de cambios (PR) proporcionan el contexto a nivel de cambio. Los ADR (documentos de requisitos de diseño) se ocupan de las decisiones a nivel de sistema. Los mensajes de confirmación también ayudan, pero no deben ser el único registro de una decisión importante.
Un antipatrón habitual: documentar cómo funciona un algoritmo de ordenación línea por línea. La verdadera pregunta es por qué se utilizó una ordenación personalizada en lugar de la biblioteca estándar. En el caso de las rutas de código personalizadas, documente la decisión que subyace a la implementación.
¿Cuáles son las mejores prácticas más importantes en materia de documentación?
Hay cinco prácticas que aumentan las posibilidades de que la documentación siga siendo útil una vez finalizado el sprint. La mayoría de los demás consejos sobre documentación dependen de que estos hábitos se pongan en práctica primero.
- Documenta mientras programas, no después. El contexto se desvanece rápidamente. Para el siguiente sprint, ya habrás olvidado qué alternativa rechazaste y por qué. Escribe el comentario explicativo en la misma confirmación que el código, o no lo escribirás en absoluto.
- Utilice una guía de estilo coherente. Elija un formato de docstring, como el estilo de Google, el estilo de NumPy, Javadoc o JSDoc, y aplíquelo en la revisión de código o en el linting. La coherencia es más importante que el formato que elija. Una guía de estilo compartida elimina la pregunta «¿cómo debo formatear esto?» y hace posible la automatización del linting.
- Considera la documentación como parte de la revisión del código. Añade comprobaciones de la documentación a tu lista de control de PR. Si una PR cambia el comportamiento, el revisor debe verificar que la documentación refleje el cambio. La documentación de prácticas de ingeniería de Google pide a los revisores que comprueben si el código está debidamente documentado. Aplica la misma regla internamente: si una PR cambia el comportamiento, los revisores deben comprobar si los comentarios, las cadenas de documentación, los archivos README y los manuales de procedimientos siguen coincidiendo.
- Elimina la documentación obsoleta. Los documentos desactualizados causan un daño real, ya que orientan a los lectores hacia una implementación, API o proceso erróneos. Revisa la documentación trimestralmente o antes de cada lanzamiento importante. Asigna la propiedad para que la documentación no sea responsabilidad de todos y, por lo tanto, de nadie.
- Asegúrate de que los ejemplos sean ejecutables. Los ejemplos de código deben ser fáciles de copiar, ejecutar y probar. Esa es la forma más segura de detectar desviaciones antes de que lo hagan los usuarios.
¿Qué herramientas debes utilizar para generar documentación de código?
Las herramientas de documentación se dividen en dos grupos: generadores tradicionales y asistentes de IA. Cada uno se encarga de tareas diferentes.
Los generadores tradicionales analizan los comentarios estructurados de tu código fuente y generan referencias navegables. El generador adecuado suele depender del lenguaje que utilices.
| Herramienta | Lenguaje/Ecosistema | Lo que genera |
|---|---|---|
| Javadoc | Java | Referencia de la API a partir de los comentarios del documento |
| JSDoc | JavaScript/TypeScript | Referencia de la API a partir de comentarios anotados |
| Sphinx | Python (compatibilidad con otros lenguajes mediante complementos) | Sitios de documentación completos desde reStructuredText o Markdown |
| Doxygen | C, C++, Java, Python y otros | Documentación de referencia multilingüe |
| Godoc | Ir | Documentación de paquetes a partir de comentarios del código fuente |
La calidad del resultado depende totalmente de tus cadenas de documentación. Estas dan formato y publican lo que has escrito. No inventan la intención que falta.
Los asistentes basados en IA añaden una segunda capa. GitHub Copilot, Cursor y Windsurf pueden redactar comentarios y cadenas de documentación dentro del editor. Mintlify puede ayudar a generar y mantener la documentación para desarrolladores a partir del código y la documentación existente. Swimm se centra en mantener la documentación interna vinculada a los cambios en el código. ReadMe y GitBook ayudan a los equipos a publicar referencias de API y documentación dirigida a los desarrolladores, a menudo con funciones de búsqueda o redacción asistidas por IA.
El estudio de Stack Overflow reveló que la documentación era la categoría de automatización mediante IA más solicitada, mencionada en aproximadamente el 33,9 % de las respuestas abiertas de los desarrolladores. Estas herramientas son más eficaces cuando el código fuente ya expone claramente el comportamiento.
La IA pierde eficacia cuando la explicación depende de decisiones tomadas fuera del código: un hilo de Slack, una reunión de planificación, un ticket o una revisión de incidencias. Puede resumir la función, pero no puede saber qué restricción era negociable, qué opción se rechazó o por qué se aceptó la solución de compromiso.
Flujo de trabajo práctico:
- Deje que la IA redacte el esqueleto: resumen de la función, parámetros, valores de retorno y excepciones comunes
- Compáralo con el comportamiento real del código
- Añada el «por qué»: la decisión, la restricción, la suposición o la alternativa rechazada
- Redacta un ADR para las decisiones a nivel de sistema
- No publique documentos generados por IA sin revisarlos previamente.
Dónde encaja ClickUp y dónde no
ClickUp no es un generador de documentación a nivel de código. No sustituirá a Javadoc, Sphinx, JSDoc ni Godoc. Ayuda con la documentación relacionada con el código: archivos README, guías de ejecución, guías de incorporación, ADR y registros de decisiones que deben permanecer vinculados a las tareas, tickets y sprints que los generaron.
ClickUp Docs te permite redactar estos documentos al mismo tiempo que realizas tu trabajo de ingeniería, y ClickUp Brain puede redactar un documento a partir del contexto de una tarea o un proyecto; a continuación, los desarrolladores pueden añadir la justificación de la decisión, las limitaciones y las compensaciones.
Para los equipos de ingeniería, esto se traduce en menos tiempo buscando entre documentos, chats y tickets dispersos, y más tiempo dedicado a conservar las decisiones que esas herramientas suelen ocultar.
Si su problema es que «nuestra documentación está técnicamente completa, pero nadie la encuentra», se trata de un problema de visibilidad. Un entorno de trabajo conectado puede ser de ayuda.
Si su problema es que «nuestra referencia de la API está desactualizada», se trata de un problema de generación y revisión. Sphinx, Javadoc, JSDoc o Godoc le serán de más ayuda que una herramienta del entorno de trabajo. No confunda ambas cosas.
¿Qué cambia cuando la IA redacta la mayor parte de la documentación?
Hay un chiste recurrente en los hilos de r/developersIndia, r/webdev y r/AskProgramming sobre la documentación de ingeniería. Cuando alguien pregunta cómo gestiona el equipo la documentación, la respuesta más habitual suele ser alguna versión de: «Yo soy la documentación».
Es gracioso porque es cierto. Durante años, la solución a la falta de documentación ha sido el ingeniero que, por casualidad, se acuerda.
La IA cambia las reglas del juego. Es capaz de redactar rápidamente la documentación rutinaria, lo que hace que las decisiones no documentadas sean más difíciles de justificar. Cuando la IA puede estructurar las partes mecánicas de tus documentos en cuestión de segundos, «ya me acordaré» deja de ser una excusa válida como sistema de registro.
Esto reorienta el trabajo del ingeniero hacia la intención, las decisiones y las compensaciones: aspectos que la sintaxis por sí sola no puede explicar.
Gran parte de los antiguos consejos sobre documentación se escribieron para un flujo de trabajo anterior a la IA. Se centran en gran medida en las descripciones de parámetros, las firmas de funciones y las notas de configuración exhaustivas.
La IA ya puede encargarse de gran parte de ese trabajo. Si los ingenieros dedican la mayor parte de su tiempo de documentación a resúmenes mecánicos, están dedicando su atención humana a la capa de menor valor.
Dedica ese tiempo a la intención: por qué existe la función, qué opción rechazaste y de qué supuestos depende el código. Esas son las notas que necesitarán tu futuro equipo, los agentes de programación de IA y el ingeniero que herede el código base en 2027.
Si su problema de documentación es la dispersión del contexto, ClickUp puede ayudarle a mantener el historial de decisiones más cerca de las tareas, los documentos y los proyectos que lo generaron.
Preguntas frecuentes sobre la documentación del código
¿Qué es un README?
Un archivo README supera su primera prueba cuando un colaborador puede encontrar rápidamente cinco cosas: qué hace el proyecto, cómo instalarlo, cómo utilizarlo, cómo contribuir y dónde obtener ayuda. Si la configuración está oculta bajo insignias, notas de arquitectura o detalles del registro de cambios, el archivo README está mal organizado.
¿Cuál es la diferencia entre los comentarios del código y la documentación?
Los comentarios del código se encuentran dentro de los archivos fuente y explican líneas o bloques específicos. La documentación suele encontrarse fuera de los archivos fuente, en archivos README, wikis, sitios de referencia generados o documentación de API. Los comentarios ayudan al siguiente desarrollador que lea tu función. La documentación ayuda a la siguiente persona que intente utilizar, ejecutar o contribuir a tu proyecto.
¿Qué es la capa de intención en la documentación del código?
La capa de intención es la parte de la documentación del código que recoge por qué existe el código, no qué hace: la decisión tomada, la compensación aceptada, la restricción que impulsó el diseño y la opción que el equipo rechazó. El código muestra el comportamiento; la capa de intención conserva la justificación. Las herramientas de IA como GitHub Copilot y Mintlify pueden redactar la capa mecánica (tipos de parámetros, resúmenes de funciones), pero no pueden inferir la capa de intención a partir de la sintaxis. Por lo general, esta se encuentra en los registros de decisiones de arquitectura, las descripciones de las solicitudes de incorporación de cambios (PR) o los comentarios que explican por qué en lugar de qué.
¿Con qué frecuencia se debe actualizar la documentación del código?
Actualice la documentación en la misma solicitud de validación de cambios (pull request) que modifica el comportamiento subyacente. Si cambia la firma de una función, la cadena de documentación cambia en esa solicitud. En el caso de los archivos README y la documentación de arquitectura, realice una revisión al menos una vez por lanzamiento o trimestralmente. La documentación desactualizada es peligrosa porque enseña a los lectores un comportamiento, una API o un proceso incorrectos.
¿Cuáles son los cuatro tipos de documentación?
El marco Diátaxis, ampliamente adoptado, divide la documentación en cuatro tipos: tutoriales (orientados al aprendizaje, para principiantes), guías prácticas (orientadas a tareas, para usuarios que resuelven un problema específico), referencia (orientadas a la información, para usuarios que buscan detalles) y explicación (orientadas a la comprensión, para usuarios que desean contexto). Mezclarlas da lugar a una documentación que nadie puede utilizar. Un archivo README que intente ser un tutorial completo puede ocultar la ruta de configuración. Una página de referencia redactada como un ensayo puede ocultar la llamada a la API.
¿Cómo se documenta el código con IA?
Utilice la IA para la capa mecánica y redacte usted mismo la capa de intención. Herramientas como GitHub Copilot, Cursor y Mintlify pueden redactar cadenas de documentación, descripciones de parámetros, valores de retorno y resúmenes de funciones directamente en su editor. Revise el borrador comparándolo con el comportamiento real del código y, a continuación, añada las partes que la IA no puede deducir: la justificación de la decisión, la restricción que la motivó, la opción que rechazó y cualquier suposición de la que dependa el código. Para las decisiones a nivel de sistema, redacta un Registro de Decisiones de Arquitectura. Nunca publiques documentos generados por IA sin que hayan pasado por una revisión humana.
¿Es fiable la documentación generada por IA?
La documentación generada por IA es útil para tareas mecánicas como descripciones de parámetros, valores de retorno y resúmenes básicos de funciones, pero sigue necesitando revisión humana. Herramientas como GitHub Copilot, Cursor, Codeium y Mintlify se encargan bien de esto. La IA no puede deducir por qué se tomó una decisión de compromiso, qué alternativas se rechazaron o qué restricción de producto, empresa o infraestructura determinó el diseño. Utiliza la IA para el primer borrador. Añade tú mismo la intención y el contexto.
¿Es necesario que todas las funciones tengan una cadena de documentación?
No. Las API públicas y cualquier función que vaya a llamar otro desarrollador necesitan cadenas de documentación. Los ayudantes privados utilizados en un solo archivo no suelen necesitarlas, a menos que la lógica no sea obvia. Documentar en exceso el código trivial crea una carga de mantenimiento sin aportar claridad. Adapta el nivel de detalle de la documentación al público de la función.
¿Cuál es la mejor herramienta para generar documentación de código?
La herramienta adecuada depende del lenguaje que utilices. Los equipos de Java usan Javadoc, los de JavaScript y TypeScript usan JSDoc, los de Python usan Sphinx, los de Go usan Godoc, y Doxygen se encarga de C, C++ y varios otros. Las herramientas asistidas por IA como Mintlify, Swimm, Copilot y Cursor pueden ayudar a redactar o mantener la documentación en diferentes partes del flujo de trabajo, pero no sustituyen a los generadores nativos del lenguaje.
¿Qué extensión debe tener un archivo README?
Lo suficientemente extensa como para responder rápidamente a lo básico: qué hace el proyecto, cómo instalarlo, cómo utilizarlo, cómo contribuir y dónde obtener ayuda. Incluye detalles más profundos sobre la configuración, la arquitectura y la API en documentos enlazados o subdirectorios.