Guindo Design
Diseño Estratégico de Producto Digital
Jeikin
Accesibilidad integrada en el flujo de trabajo de los agentes de IA
El problema que nadie quiere resolver
Llevamos muchos años diseñando herramientas y aplicando inteligencia artificial a distintos niveles, colaborando con empresas de todos los tamaños, y hay algo que se repite en cada proyecto: la accesibilidad técnica genera demasiada fricción en el desarrollo.
Los equipos quieren cumplir con todos los requisitos, pero la accesibilidad se vive como una piedra en el zapato, algo que añade complejidad, ralentiza las entregas y que nadie sabe bien por dónde empezar a resolver. Las herramientas que existen detectan problemas, pero no ayudan a corregirlos. Señalan errores y desaparecen. El desarrollador se queda solo ante un listado de warnings que no entiende.
Mientras tanto, los agentes de IA están escribiendo cada vez más código. Componentes enteros, páginas completas, flujos funcionales. Rápido, eficiente, impresionante. Pero sin ningún control de accesibilidad. La IA está diseñada para ser complaciente y consumir pocos tokens, de forma que suele priorizar resultados rápidos y generar código no accesible por defecto. Ninguna auditoría manual puede seguir ese ritmo.
La normativa europea de accesibilidad (European Accessibility Act) ya está aquí. Los equipos necesitan cumplir, pero el proceso para conseguirlo sigue roto.
El origen de Jeikin
En Guindo trabajamos con inteligencia artificial desde hace años. Cuando los agentes de IA empezaron a escribir código completo (no solo sugerir líneas, sino generar componentes, páginas y flujos enteros) vimos que producían interfaces sin ningún criterio de accesibilidad. Botones sin etiquetas, formularios sin asociación, contrastes insuficientes, navegación por teclado inexistente.
Si los agentes de IA son tan eficientes para producir código ¿por qué no pueden asegurar que sea accesible? No como un simple linter que muestra warnings en la terminal, sino como un compañero de revisión que sabe qué criterios aplican, que exige verificar que los problemas se hayan corregido, y que genere la documentación de cumplimiento automáticamente. Ese compañero es Jeikin (abre en ventana nueva).
El reto de diseño
Jeikin tenía que funcionar para tres audiencias que nunca se ven entre sí.
- El desarrollador vive en su editor, en GitHub, en la terminal. No quiere aprender una herramienta nueva. No quiere abrir otro dashboard. Quiere que la accesibilidad aparezca en su flujo de trabajo habitual, en su lenguaje, sin interrumpir lo que ya está haciendo.
- El responsable de equipo necesita exactamente lo contrario: visión de conjunto. Cuántos problemas hay abiertos, cuál es la tendencia, qué evidencia tiene para una auditoría. Necesita un dashboard, pero uno que se alimente solo, sin depender de que el equipo recuerde actualizar nada.
- Y hay un tercer usuario para el que nadie había diseñado antes: el agente de IA. Para que un agente haga una revisión de accesibilidad de calidad, necesita instrucciones claras, criterios bien definidos y un flujo estructurado que le impida saltarse pasos. Diseñar la experiencia del agente es diseñar la calidad del resultado.
Las decisiones que dan forma al producto
Invisible para el desarrollador, visible para el lead
Jeikin no es una herramienta más en el stack. Se integra directamente en el editor y en GitHub. El desarrollador pide una revisión de accesibilidad como parte de su conversación con el agente de IA, recibe hallazgos con referencia al archivo y la línea exacta, corrige, y el propio agente verifica que la corrección es válida. Sin cambiar de contexto, sin abrir otra pestaña.
El responsable de equipo, mientras tanto, ve todo el progreso en el dashboard: issues abiertos, criterios cubiertos, tendencia del proyecto, evidencia exportable. La información fluye del editor al dashboard sin que nadie tenga que hacer nada.
El desarrollador revisa accesibilidad desde su editor, sin cambiar de contexto
El responsable de equipo ve el progreso en el dashboard: issues, criterios y evidencia
Dogfooding como principio de diseño
Jeikin se audita a sí mismo. Cada pantalla, cada componente, cada texto del producto ha pasado por su propia herramienta de revisión. Esto nos obliga a resolver cada problema que detectamos antes de pedirle a nadie más que lo haga. Si Jeikin no puede cumplir sus propios criterios, no tiene autoridad para exigírselos a otros.
Transparencia y confianza
Jeikin explica qué va a hacer antes de hacerlo. Pide permiso antes de escanear código. No modifica nada sin aprobación. El código permanece en la máquina del desarrollador; solo los hallazgos llegan al dashboard.
Cada corrección se verifica automáticamente antes de marcarla como resuelta
La App de GitHub
La aplicación en GitHub (abre en ventana nueva) revisa automáticamente cada pull request. Publica hallazgos accionables directamente en el código, con el criterio de accesibilidad aplicable y enlaces que abren el archivo exacto en el editor con un solo clic. Los problemas críticos bloquean la fusión del código hasta que se corrigen. El desarrollador no necesita recordar que Jeikin existe. Jeikin aparece cuando es relevante y se retira cuando no lo es.
Jeikin publica hallazgos accionables directamente en el código del pull request
Esto es solo el principio. Jeikin no es un producto estático, sino un proyecto vivo que evoluciona cada semana. Estamos recabando feedback constante de los equipos que ya lo usan para pulir los flujos de trabajo y asegurar que la herramienta se adapta a la realidad de cada sprint. No buscamos la perfección teórica, sino una solución pragmática que evolucione al mismo ritmo que las necesidades de nuestros usuarios.