Escrito por: Nubank Editorial

Una conversación con un asistente de IA se parece a una interfaz de texto, y eso puede dar la impresión de que es accesible por naturaleza: no hay menús complejos que recorrer, no hay paneles llenos de widgets y buena parte de la interacción ocurre a través de palabras. Sin embargo, es importante decir que texto y texto accesible no son lo mismo.

Muchas de las convenciones que usamos al interactuar con asistentes de programación suponen que la persona del otro lado puede recorrer la respuesta visualmente. Una comparación se convierte en una tabla Markdown. Un cambio se comunica mediante un diff. Una arquitectura se comprime en un diagrama. Un registro de compilación extenso se pega en la conversación. Referencias como “ver arriba” o “como se muestra abajo” asumen que moverse entre distintas partes de la respuesta es trivial.

Para una persona desarrolladora que consume Claude principalmente a través de un lector de pantalla o de la función de lectura en voz alta, estas convenciones pueden comportarse de manera muy distinta. La información organizada visualmente puede convertirse en una larga secuencia de palabras desconectadas cuando se pronuncia, mientras que un código que puede recorrerse en segundos debe atravesarse de forma lineal, y una referencia espacial pierde gran parte de su utilidad cuando no hay un espacio visual al que apuntar.

Esta iniciativa surgió en el contexto de NuPlural, el Grupo de Afinidad (ERG) de Nubank para personas con discapacidad. Creada en 2021, la comunidad creció de cinco personas a más de 400 y ofrece un espacio para que las personas de Nubank con discapacidad intercambien experiencias, se apoyen mutuamente y contribuyan a construir un entorno de trabajo más seguro e inclusivo. NuPlural también trabaja para fortalecer el sentido de pertenencia y apoyar el desarrollo profesional de las personas de Nubank con discapacidad.

En este contexto, una persona de Nubank con una perspectiva y una experiencia diferentes, específicamente una Nubanker con baja visión, transformó un desafío recurrente de interacción en un conjunto práctico de instrucciones que usa a diario con Claude. La configuración también se compartió con otras personas de Nubank y puede ser utilizada por cualquiera que encuentre útil este modelo de interacción.

El resultado es un conjunto interno de instrucciones llamado BLIND-CLAUDE.md, creado en el entorno de desarrollo y referenciado desde CLAUDE.md. No modifica Claude en sí ni introduce una nueva función nativa de accesibilidad. En cambio, agrega un conjunto de instrucciones de comportamiento sobre las demás instrucciones de CLAUDE.md que ya están en vigor.

La premisa se declara directamente en el archivo: las respuestas en este contexto se “consumen principalmente por el oído (lector de pantalla / lectura en voz alta), no por la vista”. Por lo tanto, decisiones de formato que pueden ser inofensivas para la lectura visual pueden introducir fricción cuando se narran en voz alta, y eso cambia lo que se considera una buena respuesta de IA.

Cuando una buena UX visual se convierte en una UX auditiva difícil

Piensa en una tabla Markdown que compara tres opciones de implementación. Para una persona que ve, las columnas establecen relaciones casi de inmediato, ya que es posible pasar del nombre de una opción a sus ventajas, desventajas y restricciones, y luego saltar horizontal o verticalmente para hacer comparaciones.

Un lector de pantalla, en cambio, tiene que convertir esa estructura bidimensional en una secuencia. Lo que parecía conciso en pantalla puede convertirse en lo que BLIND-CLAUDE.md describe como “un muro de valores de celdas desconectados, sin estructura”. Por eso, la instrucción indica a Claude que prefiera prosa breve o listas simples en lugar de tablas densas.

El mismo problema aparece en lugares menos evidentes. Tomemos “mira el ejemplo de arriba”. Visualmente, “arriba” es una ubicación. De forma auditiva, es una instrucción para navegar hacia atrás por un flujo de información y determinar a qué sección anterior se refería quien escribió. En lugar de eso, la Skill exige que las referencias sean autocontenidas: retomar brevemente lo que importa en vez de depender de dónde aparece algo en la pantalla.

Los diagramas exponen un supuesto aún más claro. Un diagrama de flujo puede transmitir relaciones mediante la posición, las flechas, la agrupación y la dirección, pero no puede darse por sentado que esas relaciones sobrevivan cuando el artefacto se consume linealmente. BLIND-CLAUDE.md exige que los diagramas tengan un equivalente textual en lenguaje sencillo, de modo que la representación visual nunca sea la única vía de acceso a la información.

La pregunta de fondo es qué ocurre cuando la misma información se escucha en lugar de recorrerse con la vista.

Check our job opportunies

Un principio simple: diseñar la respuesta para que funcione de forma lineal

La regla central de BLIND-CLAUDE.md ofrece una prueba útil para cada respuesta:

“Toda respuesta debe tener sentido leída de arriba abajo, en voz alta y en orden.”

El archivo va más allá: comprender la respuesta no debería requerir recorrerla visualmente, saltar de un punto a otro ni volver repetidamente a un diagrama. Cuando un atajo ahorra espacio visual pero reduce la claridad para quien escucha, Claude debe elegir la claridad.

Ese principio convierte el consumo auditivo en una restricción explícita de ingeniería. En lugar de preguntar solo “¿esto es técnicamente correcto?” o “¿esto es conciso?”, al asistente se le plantea otra pregunta: “si alguien escucha esta respuesta de forma secuencial, ¿la información sigue funcionando?”. Y un ejemplo real del flujo de trabajo aclara la distinción. A Claude se le pidió:

“¿Podrías describir cómo funciona la arquitectura diplomat? Me gustaría tener esa respuesta con y sin las instrucciones de BLIND-CLAUDE.md.”

Sin las instrucciones de accesibilidad, parte de la respuesta comprimió la arquitectura en estructuras pensadas para recorrerse rápidamente con la vista. El flujo de datos, por ejemplo, se representó con flechas:

wire.in → adapter → model → logic → controller

La respuesta separó luego la información en secciones como “Flujo de datos”, “Reglas de esquema” y “Antipatrones que evitar”, usando viñetas cortas y notación compacta.

Para una persona desarrolladora que ve, ese formato tiene ventajas. Una sola mirada a las flechas comunica la dirección. Puede saltar entre secciones e inspeccionar selectivamente la regla que sea relevante.

Con BLIND-CLAUDE.md activo, Claude reorganizó esencialmente la misma explicación técnica como prosa lineal.

En lugar de que el diagrama de flechas cargara con la relación entre los componentes, la respuesta explicó primero el propósito de la arquitectura y luego presentó cada área en secuencia. Describió cómo la lógica permanece aislada de las operaciones externas de entrada y salida, qué hacen los adapters, cómo los controllers orquestan el trabajo, dónde ocurren las interacciones externas y cómo los models y los wire schemas encajan en la arquitectura.

Solo entonces narró el flujo de datos: una solicitud entrante llega a través de un wire schema, un adapter la convierte en un model interno, la lógica y los controllers operan sobre ese model, y el proceso se invierte para los datos de salida.

La distinción importante es que la segunda respuesta no exige que quien escucha reconstruya una relación visual. El contenido técnico se mantiene; lo que cambia es la arquitectura de la información.

Codificar la accesibilidad en el comportamiento de Claude

La implementación es deliberadamente ligera: las instrucciones de accesibilidad viven en BLIND-CLAUDE.md, referenciado desde CLAUDE.md. El archivo declara explícitamente que sus reglas operan sobre las demás instrucciones de CLAUDE.md que ya están en vigor.

A partir de ahí, el archivo traduce un requisito de accesibilidad —las respuestas deben funcionar cuando se escuchan— en reglas de comportamiento concretas para el asistente.

El código es un buen ejemplo. Las personas desarrolladoras que pueden ver una respuesta quizá recorran un fragmento de código y reconozcan su propósito sin leer cada token. Ese supuesto no se sostiene cuando el mismo fragmento se narra. Por eso, la Skill indica a Claude que explique qué hace el código antes del fragmento o junto a él. Incluso un fragmento corto no debería ser el único portador del sentido de la respuesta.

Esto genera un cambio sutil pero importante en la forma en que Claude comunica información técnica. La explicación pasa a ser lo principal; el código se convierte en evidencia o detalle de implementación que respalda esa explicación.

El mismo razonamiento se aplica a los diffs. Quien mira un diff suele poder entender el cambio recorriendo las adiciones y las eliminaciones. Escuchar ese mismo diff significa encontrarse con puntuación, marcadores de línea, sintaxis y código de forma secuencial. Por eso, BLIND-CLAUDE.md pide a Claude que describa los cambios en los archivos en lenguaje sencillo, en lugar de depender de la forma visual del diff para explicar lo que ocurrió.

La salida ruidosa de las herramientas recibe un tratamiento similar. Los registros de compilación, los resultados de grep y los diffs largos suelen ser útiles justamente porque una persona desarrolladora puede recorrerlos e identificar las líneas significativas. Leer esa misma salida de principio a fin cambia drásticamente ese costo. La Skill indica a Claude que primero reduzca las salidas largas de herramientas a las dos o tres líneas que realmente importan, en lugar de narrar la salida en bruto de forma literal.

La concisión en sí misma se convierte en una consideración de accesibilidad. Las instrucciones favorecen “algunas frases claras” frente a estructuras innecesariamente elaboradas, a menos que la persona pida específicamente una lista de verificación o un desglose.

El objetivo es dejar de depender de las propiedades visuales de códigos, diagramas, diffs u otros artefactos útiles como única vía hacia la comprensión.

La accesibilidad como restricción de ingeniería

Hay una idea más amplia detrás de estas instrucciones relativamente pequeñas. Los asistentes de IA suelen optimizarse en torno al contenido de sus respuestas: corrección, exhaustividad, relevancia o tono. Pero la modalidad a través de la cual se consume esa respuesta también determina si funciona.

Una respuesta técnicamente correcta puede seguir siendo difícil de usar, y eso apunta a otra capa de contexto que vale la pena codificar en los flujos de trabajo asistidos por IA: no solo qué quiere lograr la persona, sino cómo necesita comportarse la interacción misma.

En este caso, ese requisito proviene directamente del uso vivido. La persona que creó el conjunto de instrucciones tiene baja visión y lo utiliza a diario para interactuar con Claude. La configuración se compartió después con otras personas de Nubank.

Esa distinción es importante porque las instrucciones no se basan únicamente en una idea abstracta de cómo debería ser una respuesta accesible. Codifican decisiones de interacción que se están usando en un flujo de desarrollo real.

Al mismo tiempo, esto todavía no es evidencia de un patrón de accesibilidad validado universalmente. Hasta ahora no se ha recogido retroalimentación de otras personas, y la configuración no debería presentarse como representativa de las preferencias de todas las personas desarrolladoras ciegas o con baja visión. Los requisitos de accesibilidad pueden variar significativamente entre personas, herramientas, flujos de trabajo y tecnologías asistivas.

Lo que demuestra la implementación es más específico: las características de una interacción pueden traducirse en restricciones explícitas sobre la salida de la IA.

En este caso, se le indica al asistente que sus respuestas se escucharán principalmente. Esa única restricción tiene consecuencias en cascada para la arquitectura de la información. Las tablas se convierten en prosa, las referencias espaciales se vuelven referencias explícitas, los diagramas ganan equivalentes textuales y los diffs se convierten en descripciones de cambios. El código gana una explicación que lo acompaña, mientras que los registros se resumen antes de mostrar los detalles.

La persona ya no tiene que recordarle a Claude estas preferencias en cada prompt. Al trasladarlas a la capa de instrucciones, la modalidad de interacción pasa a formar parte del entorno en el que opera el asistente.

Y aunque este conjunto en particular surgió del flujo de trabajo de una sola persona, su uso no tiene por qué detenerse ahí. Las instrucciones pueden ser adoptadas también por otras personas de Nubank.

Eso también abre espacio para la iteración. El siguiente paso útil sería recoger retroalimentación de otras personas que usen la configuración y refinar las instrucciones de Claude según lo que funciona, lo que genera fricción y lo que requieren distintos flujos de trabajo. Es una oportunidad para que el conjunto evolucione con el uso, en lugar de tratarse como un conjunto de reglas terminado.

Lo que esto nos enseña sobre construir herramientas de IA

La IA generativa hace que producir información sea fácil. Eso no hace que la información resultante sea automáticamente fácil de consumir.

A medida que los asistentes de IA se integran más profundamente en los flujos de desarrollo, la forma de sus respuestas importa tanto como su precisión técnica. Una respuesta puede ser perfectamente comprensible como página y frustrante como secuencia de audio. Una abstracción visual compacta puede volverse prolija al narrarse. Una respuesta cargada de código puede exigir un esfuerzo considerable de quien no puede recorrerla visualmente.

BLIND-CLAUDE.md aborda esos problemas con una idea relativamente directa: si la interfaz principal es auditiva, escribe instrucciones que hagan que el asistente comunique para una interfaz auditiva.

Eso significa diseñar para la secuencia en lugar de la posición, para la explicación en lugar de la inferencia visual, y para la señal en lugar de la salida en bruto.

También apunta a una forma útil de pensar la configuración de la IA de manera más amplia. Las instrucciones pueden codificar más que convenciones de código, conocimiento de repositorios o flujos de trabajo preferidos. Pueden codificar restricciones sobre cómo debe presentarse y consumirse la información.

La implementación descrita aquí es pequeña, pero la pregunta de diseño que hay detrás no lo es:

¿Qué cambia cuando dejamos de suponer que una respuesta de IA será vista y empezamos a diseñarla para ser escuchada?

Check our job opportunies