Escrito por: Nubank Editorial

Uma conversa com um assistente de IA se parece com uma interface de texto, e isso pode dar a impressão de que ela é acessível por natureza: não há menus complexos para navegar, não há painéis cheios de widgets e boa parte da interação acontece por meio de palavras. No entanto, é importante dizer que texto e texto acessível não são a mesma coisa.

Muitas das convenções que usamos ao interagir com assistentes de programação pressupõem que a pessoa do outro lado consegue percorrer a resposta visualmente. Uma comparação se transforma em uma tabela Markdown. Uma alteração é comunicada por meio de um diff. Uma arquitetura é comprimida em um diagrama. Um log de build longo é colado na conversa. Referências como “veja acima” ou “como mostrado abaixo” assumem que transitar entre diferentes partes da resposta é trivial.

Para uma pessoa desenvolvedora que consome o Claude principalmente por meio de um leitor de tela ou da funcionalidade de leitura em voz alta, essas convenções podem se comportar de maneira muito diferente. Informações organizadas visualmente podem se tornar uma longa sequência de palavras desconexas quando faladas, enquanto um código que pode ser percorrido em segundos precisa ser atravessado linearmente, e uma referência espacial perde grande parte da sua utilidade quando não há espaço visual para apontar.

Essa iniciativa surgiu no contexto do NuPlural, o Grupo de Afinidade (ERG) do Nubank para pessoas com deficiência. Criada em 2021, a comunidade cresceu de cinco pessoas para mais de 400 e oferece um espaço para que Nubankers com deficiência troquem experiências, apoiem umas às outras e contribuam para a construção de um ambiente de trabalho mais seguro e inclusivo. O NuPlural também atua para fortalecer o pertencimento e apoiar o desenvolvimento de carreira de Nubankers com deficiência.

Nesse contexto, uma pessoa do Nubank com uma perspectiva e uma experiência diferentes, especificamente uma Nubanker com baixa visão, transformou um desafio recorrente de interação em um conjunto prático de instruções que utiliza diariamente com o Claude. A configuração também foi compartilhada com outros Nubankers e pode ser usada por qualquer pessoa que considere esse modelo de interação útil.

O resultado é um conjunto interno de instruções chamado BLIND-CLAUDE.md, criado no ambiente de desenvolvimento e referenciado a partir do CLAUDE.md. Ele não modifica o Claude em si nem introduz um novo recurso nativo de acessibilidade. Em vez disso, adiciona um conjunto de instruções comportamentais sobre as demais instruções do CLAUDE.md já em vigor.

A premissa é declarada diretamente no arquivo: as respostas nesse contexto são “consumidas principalmente pelos ouvidos (leitor de tela / leitura em voz alta), e não pelos olhos”. Decisões de formatação que podem ser inofensivas para a leitura visual podem, portanto, introduzir atrito quando narradas em voz alta, e isso muda o que se entende por uma boa resposta de IA.

Quando uma boa UX visual se torna uma UX auditiva difícil

Considere uma tabela Markdown comparando três opções de implementação. Para uma pessoa que enxerga, as colunas estabelecem relações quase imediatamente, já que é possível ir do nome de uma opção para suas vantagens, desvantagens e restrições, e então saltar horizontal ou verticalmente para fazer comparações.

Um leitor de tela, no entanto, precisa transformar essa estrutura bidimensional em uma sequência. O que parecia conciso na tela pode se tornar aquilo que o BLIND-CLAUDE.md descreve como “uma parede de valores de células desconexos, sem estrutura”. A instrução, portanto, orienta o Claude a preferir textos curtos em prosa ou listas simples em vez de tabelas densas.

O mesmo problema aparece em lugares menos evidentes. Tome “veja o exemplo acima”. Visualmente, “acima” é uma localização. Auditivamente, é uma instrução para navegar de volta por um fluxo de informações e descobrir a qual seção anterior a autoria se referia. Em vez disso, a Skill exige que as referências sejam autocontidas: retomar brevemente o que importa em vez de depender de onde algo aparece na tela.

Os diagramas expõem um pressuposto ainda mais claro. Um fluxograma pode comunicar relações por meio de posição, setas, agrupamento e direção, mas não se pode assumir que essas relações sobrevivam quando o artefato é consumido linearmente. O BLIND-CLAUDE.md exige que os diagramas tenham um equivalente textual em linguagem simples, para que a representação visual nunca seja a única forma de acessar a informação.

A questão de fundo é o que acontece quando a mesma informação é ouvida, em vez de percorrida visualmente.

Check our job opportunies

Um princípio simples: projete a resposta para funcionar linearmente

A regra central do BLIND-CLAUDE.md oferece um teste útil para cada resposta:

“Toda resposta deve fazer sentido lida de cima para baixo, em voz alta, em ordem.”

O arquivo vai além: compreender a resposta não deve exigir percorrê-la visualmente, saltar de um ponto a outro ou voltar repetidamente a um diagrama. Quando um atalho economiza espaço visual, mas reduz a clareza para quem está ouvindo, o Claude deve escolher a clareza.

Esse princípio transforma o consumo auditivo em uma restrição explícita de engenharia. Em vez de perguntar apenas “isto está tecnicamente correto?” ou “isto está conciso?”, o assistente passa a responder a outra pergunta: “se alguém ouvir esta resposta de forma sequencial, a informação continua funcionando?”. E um exemplo real do fluxo de trabalho deixa a distinção mais clara. O Claude recebeu a seguinte solicitação:

“Você poderia descrever como funciona a arquitetura diplomat? Gostaria de ter essa resposta com e sem as instruções do BLIND-CLAUDE.md.”

Sem as instruções de acessibilidade, parte da resposta comprimiu a arquitetura em estruturas pensadas para serem percorridas rapidamente com os olhos. O fluxo de dados, por exemplo, foi representado com setas:

wire.in → adapter → model → logic → controller

A resposta então separou as informações em seções como “Fluxo de dados”, “Regras de schema” e “Antipadrões a evitar”, usando bullets curtos e notação compacta.

Para uma pessoa desenvolvedora que enxerga, esse formato tem vantagens. Um único olhar para as setas comunica a direção. É possível saltar entre seções e inspecionar seletivamente a regra que for relevante.

Com o BLIND-CLAUDE.md ativo, o Claude reorganizou essencialmente a mesma explicação técnica em prosa linear.

Em vez de deixar o diagrama de setas carregar a relação entre os componentes, a resposta primeiro explicou o propósito da arquitetura e então apresentou cada área em sequência. Descreveu como a lógica permanece isolada das operações externas de entrada e saída, o que os adapters fazem, como os controllers orquestram o trabalho, onde acontecem as interações externas e como os models e os wire schemas se encaixam na arquitetura.

Só então narrou o fluxo de dados: uma requisição de entrada chega por meio de um wire schema, um adapter a converte em um model interno, a lógica e os controllers operam sobre esse model, e o processo é invertido para os dados de saída.

A distinção importante é que a segunda resposta não exige que quem ouve reconstrua uma relação visual. O conteúdo técnico permanece; o que muda é a arquitetura da informação.

Codificando acessibilidade no comportamento do Claude

A implementação é deliberadamente leve: as instruções de acessibilidade ficam no BLIND-CLAUDE.md, referenciado a partir do CLAUDE.md. O arquivo declara explicitamente que suas regras operam sobre as demais instruções do CLAUDE.md já em vigor.

A partir daí, o arquivo traduz um requisito de acessibilidade — as respostas precisam funcionar quando ouvidas — em regras comportamentais concretas para o assistente.

O código é um bom exemplo. Pessoas desenvolvedoras que conseguem ver uma resposta podem percorrer um trecho de código e reconhecer seu propósito sem ler cada token. Esse pressuposto não se sustenta quando o mesmo trecho é narrado. Por isso, a Skill orienta o Claude a explicar o que o código faz antes ou junto do trecho. Mesmo um trecho curto não deve ser o único portador do sentido da resposta.

Isso cria uma mudança sutil, mas importante, na forma como o Claude comunica informações técnicas. A explicação se torna o elemento principal; o código passa a ser evidência ou detalhe de implementação que sustenta essa explicação.

O mesmo raciocínio se aplica aos diffs. Quem olha um diff muitas vezes consegue entender a mudança percorrendo adições e remoções. Ouvir o mesmo diff significa encontrar pontuação, marcadores de linha, sintaxe e código de forma sequencial. O BLIND-CLAUDE.md, portanto, pede que o Claude descreva as mudanças nos arquivos em linguagem simples, em vez de depender da forma visual do diff para explicar o que aconteceu.

Saídas ruidosas de ferramentas recebem tratamento semelhante. Logs de build, resultados de grep e diffs longos costumam ser úteis justamente porque a pessoa desenvolvedora consegue percorrê-los e identificar as linhas significativas. Ler a mesma saída do começo ao fim muda drasticamente esse custo. A Skill orienta o Claude a primeiro reduzir saídas longas de ferramentas às duas ou três linhas que realmente importam, em vez de narrar a saída bruta literalmente.

A concisão em si passa a ser uma consideração de acessibilidade. As instruções favorecem “algumas frases claras” em vez de estruturas desnecessariamente elaboradas, a menos que a pessoa peça especificamente uma checklist ou um detalhamento.

O objetivo é deixar de depender das propriedades visuais de códigos, diagramas, diffs ou outros artefatos úteis como único caminho para a compreensão.

Acessibilidade como restrição de engenharia

Há uma ideia mais ampla por trás dessas instruções relativamente pequenas. Assistentes de IA são frequentemente otimizados em torno do conteúdo de suas respostas: correção, completude, relevância ou tom. Mas a modalidade pela qual essa resposta é consumida também determina se ela funciona.

Uma resposta tecnicamente correta pode, ainda assim, ser difícil de usar, e isso aponta para outra camada de contexto que vale codificar em fluxos de trabalho assistidos por IA: não apenas o que a pessoa quer realizar, mas como a própria interação precisa se comportar.

Neste caso, esse requisito vem diretamente do uso vivido. A pessoa que criou o conjunto de instruções tem baixa visão e o utiliza diariamente para interagir com o Claude. A configuração foi então compartilhada com outros Nubankers.

Essa distinção é importante porque as instruções não se baseiam apenas em uma ideia abstrata de como deveria ser uma resposta acessível. Elas codificam escolhas de interação que estão sendo usadas em um fluxo de desenvolvimento real.

Ao mesmo tempo, isso ainda não é evidência de um padrão de acessibilidade universalmente validado. Nenhum feedback de outras pessoas foi coletado até agora, e a configuração não deve ser apresentada como representativa das preferências de toda pessoa desenvolvedora cega ou com baixa visão. Requisitos de acessibilidade podem variar significativamente entre pessoas, ferramentas, fluxos de trabalho e tecnologias assistivas.

O que a implementação demonstra é mais específico: características de uma interação podem ser traduzidas em restrições explícitas sobre a saída da IA.

Neste caso, o assistente é informado de que suas respostas serão principalmente ouvidas. Essa única restrição tem consequências em cascata para a arquitetura da informação. Tabelas se tornam prosa, referências espaciais se tornam referências explícitas, diagramas ganham equivalentes textuais e diffs se tornam descrições de mudanças. O código ganha uma explicação que o acompanha, enquanto os logs são resumidos antes de os detalhes serem apresentados.

A pessoa não precisa mais relembrar o Claude dessas preferências em cada prompt. Ao movê-las para a camada de instruções, a modalidade de interação passa a fazer parte do ambiente em que o assistente opera.

E, embora esse conjunto específico tenha surgido do fluxo de trabalho de uma pessoa, seu uso não precisa parar aí. As instruções podem ser adotadas por outros Nubankers também.

Isso também abre espaço para iteração. O próximo passo útil seria reunir feedback de outras pessoas que usam a configuração e refinar as instruções do Claude com base no que funciona, no que gera atrito e no que diferentes fluxos de trabalho exigem. É uma oportunidade para que o conjunto evolua pelo uso, em vez de ser tratado como um conjunto de regras acabado.

O que isso nos ensina sobre construir ferramentas de IA

A IA generativa torna fácil produzir informação. Isso não torna automaticamente fácil consumir a informação resultante.

À medida que assistentes de IA se integram mais profundamente aos fluxos de desenvolvimento, a forma de suas respostas importa tanto quanto sua precisão técnica. Uma resposta pode ser perfeitamente compreensível como página e frustrante como sequência de áudio. Uma abstração visual compacta pode se tornar prolixa quando narrada. Uma resposta carregada de código pode exigir esforço considerável de quem não consegue percorrê-la visualmente.

O BLIND-CLAUDE.md trata desses problemas com uma ideia relativamente direta: se a interface principal é auditiva, escreva instruções que façam o assistente comunicar para uma interface auditiva.

Isso significa projetar para sequência em vez de posição, para explicação em vez de inferência visual, e para sinal em vez de saída bruta.

Isso também aponta para uma maneira útil de pensar a configuração de IA de forma mais ampla. Instruções podem codificar mais do que convenções de código, conhecimento sobre repositórios ou fluxos de trabalho preferidos. Elas podem codificar restrições sobre como a informação precisa ser apresentada e consumida.

A implementação descrita aqui é pequena, mas a questão de design por trás dela não é:

O que muda quando deixamos de assumir que uma resposta de IA será vista e começamos a projetá-la para ser ouvida?

Check our job opportunies