// artigos · ai-orchestration
Loading, empty e erro não são polimento. São feature.
IA constrói a tabela, os filtros, a paginação. Mas abre com a tabela vazia e você vê um espaço em branco. Por que isso é erro de categoria, não falta de tempo.
Peça pra uma IA construir uma listagem de itens. Ela cria a tabela, os filtros, a paginação. Tudo funciona: quando tem dados.
Agora abra com a tabela vazia. O que aparece? Nada. Um espaço em branco onde deveria ter orientação. Abra com a internet cortada. O que aparece? Um spinner que gira pra sempre. Clique num botão enquanto a query carrega. O que acontece? Ela dispara de novo.
Isso não é um bug. É o modo default de código gerado por IA.
IA constrói o que você pede. E você quase nunca pede "tela vazia", "estado de erro" ou "loading com skeleton". Ela não adiciona o que o prompt não menciona.
O que a IA pula
A IA tem um padrão previsível quando constrói UI:
| Estado | O que a IA faz | O que deveria fazer |
|---|---|---|
| Loading | Spinner genérico ou nada | Skeleton que espelha o layout final |
| Empty | Tabela vazia, espaço em branco | Microcopy orientando o próximo passo |
| Error | Console.log ou nada | Toast com ação de retry, mensagem humana |
| Keyboard | Ignora | Tab order lógico, focus ring visível, Escape fecha modais |
Cada um desses é o tipo de coisa que "funciona" sem eles. O happy path roda. Mas o usuário que abre o app pela primeira vez e vê uma tela vazia sem saber o que fazer: esse usuário desiste. E a IA nunca vai saber que ele desistiu, porque o prompt não pediu pra considerar isso.
O que eu codifiquei
Isso é o princípio 4 do Taste Loop: "feedback e acessibilidade vão com a v1". Não é polish pra depois. É feature desde o primeiro commit.
No dev757, isso tá codificado na definição de pronto: antes de declarar que uma feature tá pronta, eu exijo que o agente tenha implementado loading state, empty state, error state e navegação por teclado. Não é opcional. Não é "na próxima iteração". É na primeira passada.
O AGENTS.md do dev757 lista isso como anti-pattern: "Loading/empty/error state 'pra depois'. Viola princípio 4." Quando o agente lê isso antes de começar, ele sabe que pular estados não é um atalho: é uma violação.
Exemplo real
No Study Space, a primeira versão da IA tinha uma listagem de matérias que funcionava perfeitamente: quando o usuário já tinha matérias cadastradas. Mas o primeiro usuário (minha namorada) abriu o app pela primeira vez e viu uma tela em branco. Sem orientação. Sem "adicione sua primeira matéria". Sem nada.
Foi o princípio 4 que me fez voltar e exigir que o agente implementasse o empty state com microcopy orientativa, o skeleton loader pra queries lentas, e o toast de erro com ação de retry. Isso não foi polimento: foi a diferença entre "funciona" e "alguém consegue usar".
Como isso muda a orquestração
Quando eu orquestro IA, o prompt sempre inclui os estados. Em vez de "crie uma listagem de matérias", o prompt é: "crie uma listagem de matérias com empty state (microcopy + CTA), loading state (skeleton), error state (toast com retry) e navegação por teclado (tab order, focus ring, Escape fecha modais)".
A IA agora entrega os 4 estados junto com a feature. Não é mais trabalho: é contexto. E o contexto que você dá no prompt determina o que a IA considera parte da feature.
Como isso se conecta ao Taste Loop
O princípio 4 é o que separa uma feature que "funciona" de uma feature que "confia". No Taste Loop, confiança não é um atributo opcional: é uma condição de aprovação. Se o Prescription Filter aprova uma feature, ela precisa sair com todos os estados implementados. Se saiu sem, não saiu.
O dev757 garante isso. É o contrato que o agente assina antes de escrever a primeira linha.