Now Reading: Del sofá al PR: cuando GitHub Copilot Agent pide tu revisión
-
01
Del sofá al PR: cuando GitHub Copilot Agent pide tu revisión
Anécdotas de Domingo
El domingo suele ser ese momento en el que uno decide bajar el ritmo. Estaba en mi sofá, leyendo algún artículo sin pretensiones, cuando revisé el buzón y me encontré un correo que no esperaba: GitHub me avisaba de que tenía una revisión pendiente.
El remitente no era un compañero de equipo, sino Copilot Agent, que había generado un pull request en mi repositorio GuardarropAL para resolver un issue que yo mismo había subido el día anterior desde VS Code Insider. Sí, se puede, y sí, impresiona ver a un agente pidiendo tu revisión como si fuera un desarrollador más.
Al entrar en GitHub, ahí estaba el PR: un cambio en la Page 50109 (Nueva Entrega) para corregir la lógica de confirmación de pagos. El propio agente había documentado el problema y propuesto la solución de manera ordenada. El issue afectaba tanto a los pagos en efectivo como a los pagos con tarjeta. El resultado estaba ahí, listo para ser revisado.
El problema detectado
El flujo de “Nueva Entrega” no gestionaba correctamente la confirmación de los pagos. En efectivo, nunca se pedía confirmación al usuario antes de marcar un ticket como pagado. En tarjeta, directamente se daba por hecho que el pago estaba confirmado, lo cual generaba inconsistencias.
En otras palabras: la lógica era incompleta. Faltaban los controles adecuados y los campos Paid se estaban asignando sin validación previa.
El agente lo describió así (más o menos) en el PR:
- En efectivo: faltaba solicitar confirmación antes de marcar como pagado.
- En tarjeta: siempre se asumía pago realizado sin flujo de validación.
- La consecuencia: líneas de tickets inconsistentes y ausencia de control en los workflows.
La propuesta del agente
La solución fue bastante clara: añadir un flujo de confirmación claro y diferenciado para cada caso.
Cash Payment Flow (Efectivo):
if PaymentMethod = PaymentMethod::Efectivo then begin
if not Confirm(ConfirmCashPaymentLbl, true) then begin
Lines.Paid := false; // Usuario no confirmó el pago
Lines.Modify(true);
end else begin
Lines.Paid := true; // Usuario confirmó el pago
Lines.Modify(true);
end;
end;
Card Payment Flow (Tarjeta):
end else begin Lines.Paid := false; // Inicialmente no pagado, requiere confirmación posterior Lines.Modify(true); end;
Además, el agente aplicó buenas prácticas de AL, sustituyendo cadenas de texto incluidas hardcode (por otro agente IA
, eso ya lo contare) por variables Label comentadas de forma clara:
ConfirmCashPaymentLbl: Label '¿Confirma que el pago en efectivo ha sido recibido?', Comment="Confirmation dialog for cash payment receipt";
Experiencia esperada del usuario
Con los cambios, el flujo es mucho más controlado:
- Al hacer clic en “Nueva Entrega – Efectivo”, el sistema muestra un cuadro de confirmación.
- Si el usuario confirma, el ticket se marca como pagado.
- Si no lo hace, el ticket queda en estado no pagado.
- Para tarjeta, las líneas quedan por defecto como no pagadas, esperando confirmación posterior en la interfaz.
Lo que significa que un agente haga esto
Más allá de la corrección puntual, lo interesante es la manera de realizarse. No fue una sugerencia en un chat. Fue un proceso autónomo:
- Detectar el issue abierto.
- Analizar el código del repositorio.
- Generar un cambio consistente.
- Documentarlo con detalle.
- Y crear un PR formal solicitando revisión.
Esto es exactamente lo que se define hoy como Copilot Agent Coding: un agente autónomo que trabaja como si fuera un miembro más del equipo, con responsabilidades completas en el ciclo de vida de un issue.
Conclusiones
La primera impresión es que asusta un poco. Ese “Copilot ha solicitado tu revisión” en el correo me gusto y sorprendió. Pero también abre los ojos a un nuevo escenario: delegar trabajo rutinario a un agente y reservar el tiempo humano para la supervisión y las decisiones críticas.
El código no es perfecto, pero es válido, limpio y alineado con buenas prácticas. Y sobre todo, está enmarcado en un flujo de trabajo transparente, con commits y documentación listos para revisión.
Lo interesante es que esto no es ya teoría: es una experiencia vivida en un proyecto real (mentira 
), con un agente que actúa como desarrollador autónomo. Y en 2026, esto va a ser el pan de cada día para muchos equipos de desarrollo.
Recordad esto porque ayuda mucho
Suscríbete al canal (anima y da ese empujón a todo esto).
Pulsa «like» si te ha gustado.
Si no quieres perderte nada, ya sabes, pulsa la campana.
En los comentarios déjame cualquier idea, duda, corrección o aportación. Todo será bien bienvenido.
Nota:
ES-El contenido de este artículo ha sido generado en parte con la ayuda de IA para revisión, orden o resumen.
El contenido, las ideas ,comentarios ,opiniones son totalmente humanas. Los posts pueden basarse o surge la idea de escribirse de otro contenido se referenciará ya sea oficial o de terceros.
Por supuesto ambas humana e IA pueden contener errores.
Te animo a que en los comentarios lo indiques, para más información accede a la página sobre responsabilidad AI del blog TechSphereDynamics.
EN-The content of this article has been generated in part with the help of IA for review order or summary.
The content, ideas, comments, opinions are entirely human. The posts can be based or arises the idea of writing another content will be referenced either official or third party.
Of course both human and IA can contain errors.
I encourage you to indicate in the comments, for more information go to the page on responsibility AI of the blog TechSphereDynamics.
