Escribir, revisar y documentar código en las propuestas de un producto

A quién le sirve. Pequeños equipos de producto con pocos ingenieros que quieren que un agente escriba, revise y documente parte del código.

Qué hicieron

La fuente es una publicación promocional y da pocos detalles de cómo funciona. Devin recibe errores, funciones o reorganizaciones asignados desde Slack, Linear, Jira o su web. Escribe el código y envía una propuesta de cambio (PR) para que una persona la revise. En ChatPRD, Claire Vo dice que revisa código, actualiza la documentación o escribe todo el código de cada propuesta.

Cómo salió

Claire Vo dice que Devin es el segundo mayor colaborador de ChatPRD, solo por detrás de ella. Sahil Lavingia afirma que es el mayor colaborador de código de Gumroad, con más de 1.500 propuestas aceptadas, unas 10 al día. Las dos son afirmaciones de los fundadores, sin medición independiente.

Conviene saber

El año gratuito es para clientes nuevos de Devin que sean suscriptores Insider. Incluye 50 ACU al mes, que la publicación equipara a una semana de trabajo de un ingeniero a jornada completa.

Qué necesitas

• Una cuenta de Devin con un plan de pago
• Tus repositorios, que son las carpetas donde vive el código, conectados a Devin
• Slack, Linear o Jira, para asignarle tareas
• Pruebas automáticas en tu proyecto
• Ingenieros que revisen cada propuesta de cambio

Cómo hacerlo tú, paso a paso

1. Conecta Devin a tus repositorios y a Slack, Linear o Jira.
2. Empieza asignándole tareas pequeñas, como actualizar documentación o corregir errores sencillos con pruebas claras.
3. Usa el prompt de la ficha: que lea el código afectado, haga el cambio, actualice la documentación y describa qué cambia y por qué.
4. Revisa cada propuesta de cambio (PR) como la de cualquier compañero antes de aceptarla.
5. Pídele también que revise las propuestas de tu equipo y que te señale posibles problemas.
6. Apunta cuántas propuestas aceptas, cuántas descartas y por qué.
7. Cuando tengas datos propios, decide qué tareas le das y cuáles no.

Esta es la tarea: [descripción del error, la función o la reorganización] en el proyecto [nombre]. Léete el código afectado, haz el cambio, actualiza la documentación relacionada y escribe una descripción clara de qué cambia y por qué. Habrás terminado cuando las pruebas pasen y la propuesta esté lista para revisión. No la aceptes tú: la revisará una persona antes de incorporarla.

Consejos

• Las cifras del caso las dan los propios fundadores y la fuente es promocional. Mide las tuyas.
• Pide que cada propuesta explique qué cambia y por qué. Hace la revisión más fácil.
• Nada debe entrar al código principal sin que una persona lo revise.

Preguntas frecuentes

Fuentes

• lennysnewsletter.com ↗

En el directorio desde el 3 de octubre de 2026.