Encargar a Devin cambios de código pequeños y acotados

A quién le sirve. Equipos con un producto de software y un repositorio en GitHub (la carpeta del código con su historial de cambios) que tienen una lista de arreglos pequeños pendientes y poco tiempo para hacerlos.

Qué hicieron

El equipo de RunLLM conectó Devin a su repositorio de GitHub. Devin revisó el código y probó los pasos de instalación. Le escribían descripciones breves, como el formato de un gráfico circular, un caso límite de una API o una frecuencia de actualización por defecto. Devin planificaba, editaba, pasaba revisores de código y pruebas y abría una pull request (una propuesta de cambio). El equipo tardaba unos cinco minutos en probar cada resultado, y los comentarios en la propuesta permitían pedir más cambios.

Cómo salió

Las tareas pequeñas de un solo componente llevaban uno o dos minutos de redacción y cinco de prueba, frente a una hora aproximada a mano. Una tarea completa con tabla nueva, llamada a una API y un botón fracasó y la reescribió el equipo.

Conviene saber

Las tareas pequeñas costaron de 1 a 5 ACU (2 a 10 $), con un precio de 500 $ por 250 ACU. Las tres tareas grandes costaron de media unas 20 ACU y dos no dieron nada útil.

Qué necesitas

• Una cuenta de Devin, que se paga por unidades de trabajo (mira sus tarifas)
• Un repositorio en GitHub que Devin pueda leer y modificar
• Una lista de tareas pequeñas y bien definidas
• Pruebas automáticas en el proyecto, para que Devin compruebe sus cambios
• Alguien que sepa revisar código y juzgar cada propuesta de cambio

Cómo hacerlo tú, paso a paso

1. Conecta Devin a tu repositorio de GitHub y deja que lea el código y pruebe los pasos de instalación.
2. Elige un arreglo pequeño y bien definido, de un solo componente, como el formato de un gráfico o un caso límite de una API (la vía por la que otros programas usan el tuyo).
3. Descríbelo en dos o tres frases con el prompt de la ficha.
4. Deja que Devin planifique, edite, pase las pruebas y abra una pull request, que es una propuesta de cambio que tú revisas antes de aceptarla.
5. Prueba el resultado tú o alguien de tu equipo. El equipo del caso tardaba unos cinco minutos por tarea.
6. Si hace falta un ajuste, pídelo con comentarios en la propia pull request.
7. Si una tarea parece más grande de lo descrito, páralo y trocéala en varias pequeñas.

En el repositorio [URL del repositorio], arregla [problema pequeño y bien definido, por ejemplo el formato del eje de un gráfico o un caso límite de la API con un valor vacío]. Añade o actualiza las pruebas, comprueba que pasan y abre una pull request con una descripción clara del cambio. Mantén el alcance estrecho y no toques código ajeno al problema. Si la tarea parece mayor de lo descrito, para y pregúntame. Habrás terminado cuando la pull request esté abierta con las pruebas pasando.

Consejos

• Mantén las tareas pequeñas. En el caso, la tarea completa con tabla nueva, llamada a una API y botón fracasó y el equipo la reescribió.
• Mira lo que gasta cada tarea y corta las que se alargan. Las grandes costaron mucho más y dos no sirvieron para nada.
• No aceptes ninguna pull request sin revisarla, aunque las pruebas pasen.

Preguntas frecuentes

Fuentes

• frontierai en Substack ↗
• @alanwest en DEV ↗

En el directorio desde el 3 de octubre de 2026.