Los agentes se volvieron forma estándar de trabajar con código. GitHub adoptó la creación y edición de código basada en agentes para muchas de sus iniciativas, incluyendo el piloto de un agente que apoya su compromiso con la accesibilidad.
¿Qué hace el agente de accesibilidad?
GitHub está piloteando un agente experimental de accesibilidad de propósito general con dos objetivos principales:
- Entregar a los ingenieros respuestas confiables y just-in-time a dudas de accesibilidad dentro de GitHub Copilot CLI y la integración Copilot para VS Code.
- Detectar y remediar automáticamente issues simples y objetivos de accesibilidad antes de que lleguen a producción.
Para el segundo objetivo, el agente evalúa de manera automática los cambios que modifican el código de frontend. A la fecha, el agente revisó 3.535 pull requests, con una tasa de resolución del 68%.
En orden de frecuencia, los cinco tipos de problema más comunes que el agente resuelve son:
| # | Tipo de issue de accesibilidad |
|---|---|
| 1 | Hacer claras la estructura y las relaciones para tecnologías asistivas |
| 2 | Entregar nombres claros y concisos para controles interactivos |
| 3 | Asegurar que los usuarios reciban anuncios importantes |
| 4 | Garantizar alternativas de texto para contenido no textual |
| 5 | Mover el foco de teclado a través de páginas y vistas en orden lógico |
Cada uno de estos tipos representa fricción y barreras que se eliminan automáticamente y que de lo contrario habrían dificultado el uso de GitHub para personas que dependen de tecnología asistiva.
¿Por qué importa ahora y no en cinco años?
El European Accessibility Act ya está en vigor, y el Título II del Americans with Disabilities Act establecerá el cumplimiento de WCAG 2.1 AA como la definición legal de "terminado" en abril de 2027. Los agentes con LLM pueden leer y actuar sobre el árbol de accesibilidad, que es una representación estructurada del DOM pensada para tecnologías asistivas.
Sin embargo, según el equipo de GitHub, las organizaciones quedarán en desventaja si no han invertido antes en identificar y remediar manualmente los issues de accesibilidad. Hay varias razones, incluida la construcción de un agente como este: GitHub ya tenía un sistema maduro con template estructurado de reportes, pasos de reproducción, metadata rica de severidad, crosslinks al PR que resolvió cada issue y criterios de aceptación, todo centralizado en un repositorio único. Ese corpus consistente y estructurado fue ideal para alimentar al agente.
¿Por qué dos sub-agentes y no uno?
El agente comenzó siendo un único agente monolítico, pero rápidamente superó las limitaciones de ese diseño. Por eso evolucionó a una arquitectura con dos sub-agentes específicos:
- El primero actúa como revisor pasivo e investigador.
- El segundo actúa como implementador activo.
Los dos sub-agentes están aislados y no pueden pasarse contenido directamente entre sí. En cambio, generan una salida estructurada según una plantilla, que el agente orquestador principal consume, valida y enruta. Las razones de este diseño:
- Checkpoints de escalamiento: el revisor marca dónde es probable que se necesite intervención humana (fallas WCAG de alta severidad, patrones difíciles de hacer accesibles).
- Comportamiento según complejidad: si el código subyacente se considera demasiado complejo, el agente opera en modo solo-guía.
- Filtrado: el revisor entrega todo lo que encuentra; el orquestador decide qué es relevante.
- Trazabilidad: la comunicación indirecta deja un audit trail completo de decisiones.
El equipo también descubrió que ejecutar las instrucciones en orden lineal fijo (no en paralelo) era clave para la precisión, contradiciendo el consejo común de paralelizar sub-agentes.
¿Dónde sigue fallando el agente?
GitHub identificó honestamente sus límites:
- Evaluación de complejidad: un script en shell analiza el código y le asigna un score; si supera el umbral, el agente NO ejecuta cambios y deriva al equipo humano de accesibilidad.
- Patrones de alto riesgo bloqueados: drag-and-drop, toasts, editores de texto enriquecido, tree views y data grids quedan fuera del alcance del agente, porque requieren atención detallada que está fuera de las capacidades actuales del LLM.
- Anti-gaming: hubo que añadir instrucciones explícitas para evitar que el modelo busque formas creativas de generar código cuando estaba instruido a no hacerlo.
- Cobertura de WCAG: de los 55 Success Criterion totales de WCAG nivel A y AA, solo 35 pueden detectarse con checkers automáticos deterministas. Eso significa que ~36% de los criterios no se descubre automáticamente. Los agentes con LLM están avanzando sobre esa brecha, pero no son una ciencia perfecta.
¿Qué se llevan los equipos de Chile que construyen agentes propios?
Tres lecciones replicables: invertir primero en catalogar issues con plantilla estructurada (sin esa data, el agente carece de corpus); usar pocas sub-agencias con responsabilidades específicas (no un enjambre paralelo); y reconocer explícitamente patrones de alto riesgo donde el agente debe declinar. Para pymes chilenas que están adoptando Copilot bajo Github Enterprise (planes desde USD 19 por usuario al mes), el agente de accesibilidad estará disponible cuando salga del piloto.
