Explorar el código para escribir documentación técnica

A quién le sirve. Redactores técnicos, equipos de producto y programadores que tienen que documentar una API (la puerta por la que otros programas usan el tuyo) o un programa sin conocer todo el código; es una herramienta para equipos técnicos.

Qué hicieron

Devin Logan, la única redactora técnica de Fern, usa el ingeniero de IA Devin, que ya conoce todos los repositorios de Fern, para explorar el código antes de escribir. También etiqueta a Fern Writer, un agente de Slack basado en Devin, en una conversación de ingeniería, y este abre una petición de cambio con páginas redactadas, contenido reorganizado y redirecciones. Después baja la rama y sigue iterando en local con Claude Code.

Cómo salió

Cuenta unas 20.000 líneas nuevas de documentación al mes en unas 500 páginas. Revisa y edita cada página, a menudo mucho. Los primeros borradores de Fern Writer a veces estructuraban mal o se saltaban una entrada del registro de cambios.

Conviene saber

La revisión del ingeniero siguió siendo clave: en una reescritura de la documentación de autenticación, el ingeniero vio que el planteamiento conceptual era erróneo y hubo que reestructurar.

Qué necesitas

• Acceso a Devin, el ingeniero de IA, conectado a los repositorios del código que vas a documentar (plan de pago)
• El código guardado en un repositorio de Git, el sitio donde se guarda el código con su historial
• Un ingeniero que revise la parte técnica
• Un lugar donde guardar la documentación, por ejemplo una carpeta del propio repositorio

Cómo hacerlo tú, paso a paso

1. Conecta Devin a los repositorios del producto que vas a documentar.
2. Pega el prompt de la ficha con el módulo o la API, el público al que va dirigido y lo que debe cubrir.
3. Pídele que explore el código y que marque lo que no tenga claro.
4. Lee el borrador con el código delante, o con un ingeniero al lado, y comprueba los ejemplos.
5. Pide a un ingeniero que revise el planteamiento general. Una explicación bien escrita puede estar mal planteada.
6. Edita a fondo y guarda el texto en la carpeta de documentación. Confirma los cambios solo cuando estén revisados.

Explora el código de [ruta o módulo] y escribe documentación técnica de [función o API] dirigida a [público, por ejemplo programadores nuevos]. Cubre qué hace, cómo se configura, las funciones o puntos de acceso principales con ejemplos y los errores habituales, y marca lo que no tengas claro para que lo verifique. Guarda el resultado en [nombre del archivo]. Habrás terminado cuando el borrador esté guardado. Enséñamelo antes de confirmar ningún cambio.

Consejos

• Pide que marque lo que no tiene claro en lugar de rellenar huecos. Los huecos inventados son el mayor riesgo.
• Comprueba cada ejemplo de código ejecutándolo.
• Revisa que no se salte páginas relacionadas ni entradas del registro de cambios.

Preguntas frecuentes

Fuentes

• buildwithfern.com ↗

En el directorio desde el 3 de octubre de 2026.