Corregir un error en una web en producción con Devin

A quién le sirve. Equipos de desarrollo que quieren delegar arreglos pequeños a un agente y revisar el resultado; si no programas, te sirve para saber qué revisar cuando un proveedor lo use.

Qué hicieron

Dentro de una prueba de cinco días, el analista pidió a Devin, un agente que trabaja en el navegador con su propio editor, su terminal y el código, que arreglara un error en una web en producción. El error era un interruptor interno (un valor de verdadero o falso) que había que cambiar de verdadero a falso. Devin lo localizó y abrió una propuesta de cambio (pull request). Después el analista le preguntó en un comentario por qué había cambiado otras cosas.

Cómo salió

La propuesta llegó en unos diez minutos con el interruptor corregido. Pero también hizo cambios sin relación, entre ellos quitar una comprobación de seguridad que debía quedarse. Su explicación de uno de los cambios era errónea, y la dio con total seguridad.

Conviene saber

Revisa con cuidado las diferencias de la propuesta. Devin tocó código que no tenía que ver y las razones que da para esos cambios pueden ser falsas.

Qué necesitas

• Una cuenta de Devin, el agente de programación que trabaja en el navegador.
• Acceso del agente al repositorio de tu web.
• La descripción exacta del error: dónde ocurre, qué esperabas y qué pasa.
• Alguien que sepa leer las diferencias de código y revisarlas.
• Un entorno de pruebas donde comprobar el arreglo antes de publicar.

Cómo hacerlo tú, paso a paso

1. Da a Devin acceso al repositorio y describe el error con precisión.
2. Pídele el arreglo más pequeño posible y que abra una propuesta de cambio (pull request) con todo lo que ha modificado.
3. Dile de forma expresa que no quite comprobaciones de seguridad ni toque código que no tenga que ver con el error.
4. Revisa línea a línea las diferencias de la propuesta, no solo la descripción.
5. Si ha cambiado algo ajeno, pídele que lo revierta y que explique por qué lo tocó. Comprueba si la explicación es cierta.
6. Prueba el arreglo en un entorno de pruebas y únelo a la rama principal solo cuando todo esté revisado.

Hay un error en [nombre del repositorio]: [describe el error, por ejemplo un interruptor que se lee mal en un archivo o función]. Encuentra la causa y abre una propuesta de cambio con el arreglo más pequeño posible. No quites comprobaciones de seguridad ni toques código que no tenga que ver. Habrás terminado cuando la descripción de la propuesta enumere todo lo que has cambiado para que yo lo revise.

Consejos

• En el caso, Devin quitó una comprobación de seguridad que debía quedarse. Lo que mejor sirve de protección es leer las diferencias.
• No te fíes de sus explicaciones sin comprobarlas. Una de ellas era errónea y la dio con total seguridad.
• Nunca dejes que publique en producción sin que una persona haya revisado antes.

Preguntas frecuentes

Fuentes

• techpoint.africa ↗

En el directorio desde el 12 de octubre de 2026.