Por qué cuesta atribuir los errores del código generado por GitHub Copilot
El autocompletado en línea tiene un perfil de riesgo distinto al de un agente que reescribe archivos. Cada sugerencia es lo bastante pequeña como para parecer revisable, así que la revisas en un segundo y sigues adelante. Ese segundo de atención es honesto con la línea que tienes delante y ciego con el sistema que la rodea.
La consecuencia es que, cuando algo se rompe, hacer bisect es un suplicio. No hay un único commit sospechoso, solo una larga cola de autocompletados aceptados que en su momento parecían correctos.
Las tres derivas que conviene vigilar
Deriva de convenciones
Los autocompletados siguen patrones de su entrenamiento y del código cercano, que no siempre coinciden con la convención real de tu base de código.
El manejo de errores, las comprobaciones de nulos y el registro de logs divergen poco a poco entre módulos.
Lógica duplicada
Aceptar una función auxiliar generada es más rápido que buscar la que ya existe, así que la misma regla acaba implementada en tres sitios.
Más adelante, una de ellas se corrige y las otras dos no.
Valores por defecto plausibles
Un valor por defecto, un tiempo de espera o un criterio de ordenación sugerido parece razonable y no coincide con la regla de tu producto.
Nada falla. Sencillamente, el comportamiento no es el que nadie pretendía.
Las tres son invisibles en la revisión y visibles cuando el producto se ejecuta, y eso es lo que determina dónde debe ir la comprobación.
Verifica el comportamiento con una cadencia, no con cada autocompletado
Verificar cada sugerencia aceptada no es posible ni útil. La unidad adecuada es el pull request: para entonces ya existe un conjunto coherente de cambios, y sigue siendo lo bastante pequeño como para razonar sobre él si algo va mal.
Lo que quieres comprobar no es el código nuevo, sino el comportamiento dentro del cual vive ese código. Un pull request que tocó el módulo de facturación debería ejercitar la facturación de extremo a extremo, incluidos los caminos en los que el autor no pensó, porque ahí es justamente donde se esconde un valor por defecto plausible.
Instalar la skill de verificación permite que el agente lo haga por su cuenta, en lugar de depender de que una persona se acuerde.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
El panel cubre lo mismo para quien no quiera una instalación local, y el conjunto completo de comandos está en el repositorio de la CLI.
La pregunta sobre regresiones que nadie se hace a tiempo
La pregunta útil sobre una base de código llena de autocompletados no es «¿este código es bueno?». Es «¿el producto sigue haciendo lo que hacía el mes pasado?». Son preguntas distintas y solo la segunda detecta la deriva.
Responderla exige un conjunto de comprobaciones anteriores al cambio, que es justo la parte que los equipos posponen. Diez flujos escritos en la primera semana valen más que cien escritos después del primer incidente, porque solo esos diez se definieron antes de que nadie supiera cuáles iban a importar.
El hábito de revisión que escala
Revisar cada autocompletado no es posible, y no revisar ninguno es la forma en que se acumula la deriva. El hábito que funciona es revisar por categorías en lugar de por líneas.
Cuando un autocompletado introduce un camino de error, comprueba que encaje con la forma en que el resto del módulo gestiona los errores, porque la divergencia aquí es la deriva más habitual y la más molesta de desenredar después. Cuando introduce un valor por defecto, pregúntate de dónde salió ese valor, porque un valor por defecto plausible es la manera más silenciosa de cambiar el comportamiento. Cuando introduce una función auxiliar, dedica diez segundos a buscar la que ya existe, porque la lógica duplicada es lo que hace que una corrección posterior quede incompleta.
Cada una de esas tres comprobaciones lleva unos segundos y detecta la mayor parte de lo que se acumula. Todo lo demás se detecta mejor ejercitando el producto que leyéndolo.
Hazlo automático
La deriva es gradual, así que la comprobación tiene que ser aburridamente regular. Cualquier cosa que dependa de que alguien se acuerde se saltará justo en la semana de más trabajo, que es cuando se aceptan más autocompletados.
Si el pipeline pertenece a otro equipo, la GitHub App es el camino de menor resistencia: es un webhook, no cambia nada en tu repositorio y se dispara cuando tu build informa de que la nueva versión está en producción. Si prefieres que la comprobación se vea en el repositorio, un paso de GitHub Actions se encarga de eso.
Detectar la deriva sin leer cada autocompletado
Revisar cada sugerencia aceptada no es posible, así que TestSprite comprueba el comportamiento dentro del cual vive el código. La cobertura se genera a partir de tu producto, se ejecuta en cada pull request y responde a la pregunta que importa en una base de código llena de autocompletados: ¿esto sigue haciendo lo que hacía el mes pasado?
Eso detecta las tres derivas de forma directa. Un valor por defecto plausible que cambió un criterio de ordenación aparece como un flujo que se comporta de otra manera. La lógica duplicada aparece cuando una copia se corrige y la otra no. La deriva de convenciones en el manejo de errores aparece como un camino que ahora falla en silencio.
Se ejecuta donde está el cambio, como un comentario en el pull request o una comprobación del commit, de modo que una regresión apunta a un lote de autocompletados y no a un trimestre entero de ellos.
¿El código generado por Copilot es peor que el escrito a mano?
En la mayoría de los casos, no línea a línea. El riesgo es volumétrico: entra más código en el repositorio por hora del que el proceso de revisión fue diseñado para absorber, así que la misma tasa de defectos deja escapar más.
¿Lo arreglaría una revisión más estricta?
En parte, y va en contra del motivo por el que se usa el autocompletado. Pasar la comprobación de la lectura a la verificación del comportamiento mantiene la velocidad y recupera la red de seguridad.
¿Y las pruebas que escribe Copilot?
Útiles para la cobertura, débiles como comprobación independiente. Una prueba generada a partir de las mismas suposiciones que el código coincide con el código por construcción.
¿Cuántos flujos deberíamos cubrir primero?
Empieza por el puñado que le mostrarías a un cliente, más cualquier camino que toque dinero o permisos. Amplía a partir de los incidentes, no de un objetivo de cobertura.
¿Hace falta acceso al repositorio?
La verificación se ejecuta contra la aplicación desplegada a través de su interfaz. El acceso al repositorio solo se usa para publicar los resultados en los pull requests y los commits.
El error es la deriva, no la sugerencia.
Los errores del código generado por GitHub Copilot se acumulan a lo largo de muchos autocompletados pequeños aceptados. Verifica el comportamiento por pull request en lugar de por sugerencia, define los flujos antes de necesitarlos y mantén la comprobación funcionando de forma automática.