Delegar ou Abdicar: O Novo Problema Central do Design de Produto
"O agente trabalhou. O usuário confirmou. Tudo ocorreu como esperado.
Exceto que o usuário não entendeu o que confirmou. Nunca entendeu.
E nunca precisou — até o dia em que precisou."
Nos três artigos anteriores desta série, acompanhamos uma transformação em camadas.
O vibe coding acelerou a geração de código e trouxe consigo uma ressaca técnica que a indústria ainda digere. Os agentes assumiram tarefas operacionais antes exclusivamente humanas e redefiniriam o papel do desenvolvedor. A interface perdeu centralidade operacional e passou a funcionar como camada de observabilidade.
Mas existe uma pergunta que ficou sem resposta direta.
Se o software agora é operado por agentes — e o humano passou a supervisionar em vez de executar — o que acontece com o usuário de produto?
Não o desenvolvedor.
O usuário de um SaaS de RH, de uma plataforma de marketing, de um sistema de atendimento.
Esse usuário também virou monitor.
E a maioria dos produtos não foi projetada para isso.
De operador a monitor
Durante décadas, a relação entre usuário e software foi direta e simétrica.
O usuário clicava. O sistema respondia. O usuário via o resultado. O usuário clicava de novo.
Cada ação tinha feedback imediato e escopo claro. O usuário entendia o que havia feito porque havia feito pessoalmente.
Com agentes, essa simetria quebra.
O usuário descreve uma intenção. O agente interpreta, planeja e executa uma sequência de ações. O resultado aparece depois.
Entre a intenção e o resultado, existe um espaço opaco onde decisões foram tomadas, dados foram lidos, ações foram executadas — tudo sem presença ativa do usuário.
Esse espaço é o problema central do design de produto agentic.
Não é um problema técnico. É um problema de governança embutida em produto.
O paradoxo da automação
Em 1983, a engenheira Lisanne Bainbridge publicou um artigo que se tornaria referência no design de sistemas de controle.
O título era "Ironies of Automation".
A ironia central que ela identificou era esta:
Quanto mais eficiente é o sistema automático, mais crítica — e menos provável — se torna a capacidade do operador humano de intervir corretamente numa emergência.
O argumento era simples e perturbador.
Sistemas automatizados funcionam bem na maior parte do tempo. O operador humano começa a confiar no sistema. Gradualmente, deixa de exercitar o julgamento que seria necessário para intervir. Quando o sistema falha — exatamente quando o humano mais precisa agir — ele não tem mais o contexto, a prática, nem a atenção para fazê-lo com eficiência.
A automação cria a própria fragilidade que deveria prevenir.
Em 1983, Bainbridge falava de usinas nucleares e cockpits de avião.
Em 2026, ela poderia estar falando de qualquer produto SaaS com agentes de IA.
O mecanismo é idêntico.
O usuário aprova fluxos sem lê-los porque geralmente estão certos. O usuário ignora notificações porque geralmente são irrelevantes. O usuário deixa de entender o sistema porque o sistema "funciona".
Até o dia em que não funciona.
E nesse dia, o usuário não tem contexto para diagnosticar, não tem histórico mental para comparar, não tem modelo do que o agente fez para saber onde começar a procurar o problema.
O paradoxo da automação não é uma falha do usuário.
É uma falha de design.
A abdição silenciosa
Existe uma diferença fundamental entre delegar e abdicar.
Delegar é transferir a execução de uma tarefa mantendo clareza sobre o escopo, os critérios de aceitação e os mecanismos de verificação.
Abdicar é transferir a execução e desligar a supervisão.
A maioria dos produtos agentic hoje facilita abdição.
Não por má intenção.
Por padrão de design.
O botão é "Executar", não "Executar com estes critérios e me avisar se qualquer um deles for violado".
A notificação diz "Tarefa concluída", não "Estas 7 ações foram executadas — 2 delas merecem revisão".
O histórico mostra o resultado, não o processo.
O fluxo de aprovação é uma tela com "Confirmar" e "Cancelar" — sem contexto do que está sendo confirmado.
Esse design não é neutro.
Ele treina o usuário a aprovar sem entender.
E à medida que os agentes ganham mais autonomia e escopo, o custo dessa aprovação inconsciente cresce.
Um agente que reorganiza pastas errou de forma barata.
Um agente que envia comunicações para clientes, executa transações ou altera configurações de sistema errou de forma cara.
O produto não pode tratar esses casos com a mesma interface.
Controle binário não é controle
O modelo atual de interação com agentes em produtos é, na maioria dos casos, binário.
Rodar ou parar. Aprovar ou cancelar. Aceitar ou rejeitar.
Isso cria uma ilusão de controle.
O usuário sente que tem poder de decisão porque existe um botão de interrupção.
Mas "parar tudo" e "continuar como está" não são as únicas — nem as mais úteis — formas de exercer supervisão.
O que usuários precisam, na prática, é de controle graduado:
- pausar a execução neste passo específico e continuar depois
- rejeitar esta ação isolada sem cancelar o fluxo inteiro
- ajustar um parâmetro antes de permitir que o agente continue
- pedir que o agente refaça apenas uma etapa com outra abordagem
- aprovar a direção geral mas exigir confirmação em ações de alto impacto
- escalar uma decisão para outro usuário sem interromper o restante
Nenhum desses comportamentos é exótico.
São exatamente os mecanismos que qualquer gerente usa ao delegar tarefas a um colaborador humano.
A questão é que o software nunca precisou modelar essa granularidade porque humanos não executavam tarefas de forma autônoma dentro de sistemas.
Agora precisam.
E o gap entre o que os produtos oferecem e o que os usuários precisam para supervisionar agentes com responsabilidade é enorme.
Intervenção proporcional ao risco
Nem toda ação de um agente carrega o mesmo peso.
Criar um rascunho, renomear um arquivo, formatar um relatório — são ações de baixo impacto, facilmente reversíveis, com consequências limitadas.
Enviar um e-mail para clientes, publicar conteúdo, modificar configurações de acesso, executar uma transferência financeira — são ações de alto impacto, difíceis ou impossíveis de reverter, com consequências potencialmente severas.
Tratar essas duas categorias com a mesma interface é um erro de design com consequências reais.
A solução não é exigir confirmação para tudo — isso cria fadiga de aprovação e leva de volta à abdição.
A solução é projetar intervenção proporcional ao risco.
Uma taxonomia possível:
| Nível | Tipo de ação | Modelo de intervenção |
|---|---|---|
| Baixo | Reversível, sem efeito externo | Execução automática + log passivo |
| Médio | Irreversível internamente, sem efeito externo | Visibilidade ativa + override disponível |
| Alto | Efeito externo ou irreversível com impacto | Confirmação ativa com contexto exibido |
| Crítico | Produção, financeiro, comunicação externa | Aprovação explícita com resumo e rastreabilidade |
Esse modelo existe há décadas em domínios onde automação e risco coexistem: aviação, controles industriais, medicina, infraestrutura crítica.
O SaaS está chegando tarde a essa conversa.
Mas está chegando porque não tem mais como evitar.
Quando um agente pode enviar comunicações, alterar dados de clientes ou disparar integrações externas, o produto precisa ter uma política de risco embutida na interface — não apenas nos logs de auditoria para engenharia.
Essa política precisa ser visível, configurável e compreensível pelo usuário final.
O que produtos fazem hoje
O ecossistema ainda está encontrando o caminho.
Alguns produtos já se movem na direção certa, mesmo que parcialmente.
Claude Code transmite em tempo real cada ação do agente: arquivos lidos, comandos executados, arquivos modificados. O usuário pode ver exatamente o que está acontecendo e interromper a qualquer momento. O problema é que o volume de informação foi projetado para desenvolvedores — não para usuários de produto.
Copilot Workspace mostra um plano antes da execução. O usuário aprova a direção antes que qualquer ação ocorra. É um passo importante, mas a granularidade ainda é de plano, não de ação individual. Aprovar o plano não significa aprovar cada passo dentro dele.
Cursor exibe diffs em tempo real enquanto o agente modifica código. Cria um modelo mental de revisão familiar para desenvolvedores. Fora do contexto técnico, esse padrão não se traduz facilmente.
Devin apresenta um log de trabalho que registra o que o agente fez. É melhor que nada, mas é majoritariamente post-hoc — o usuário vê depois do fato, não durante.
A maioria dos produtos SaaS com funcionalidades de IA — assistentes de escrita, automações de CRM, agentes de atendimento — mostra apenas o resultado. O processo é completamente opaco.
O padrão dominante ainda é:
"O agente fez algo. Aqui está o resultado. Gostou?"
Isso não é supervisão.
É degustação.
O frontend precisa projetar tensão, não eliminar atrito
Existe um princípio que dominou o design de produto nas últimas duas décadas:
Remova atrito em cada etapa.
Esse princípio foi extraordinariamente útil para tornar software acessível, intuitivo e adotado em escala.
Mas ele foi desenvolvido para um mundo onde humanos executavam ações e as consequências eram localizadas.
No mundo agentic, esse princípio aplicado sem critério se torna perigoso.
Porque nem todo atrito é falha de UX.
Algum atrito é governança.
A confirmação antes de enviar um e-mail em massa existe porque o custo de um erro é alto e irreversível. Remover essa confirmação não melhora a experiência — elimina uma proteção necessária.
O mesmo princípio se aplica a agentes.
Quando um agente está prestes a executar uma ação de alto impacto, a fricção da confirmação não é um problema de design a ser resolvido.
É o design funcionando corretamente.
O novo princípio do design agentic não é "elimine atrito".
É:
Elimine atrito desnecessário. Preserve atrito proporcional ao risco.
Essa distinção parece sutil.
Na prática, ela separa produtos que os usuários confiam de produtos que os usuários eventualmente culpam.
Conclusão
Nos artigos anteriores desta série, discutimos como a IA transformou a engenharia de software e como a interface perdeu sua centralidade operacional.
Este artigo trata de uma consequência que ainda está sendo ignorada pela maioria dos produtos.
Quando o agente passa a agir pelo usuário, o produto precisa escolher entre dois modelos:
Abdição: o usuário entrega a tarefa, não vê o processo, recebe o resultado e aprova retrospectivamente. Conveniente no curto prazo. Frágil no longo prazo.
Delegação: o usuário define intenção, mantém visibilidade proporcional ao risco, retém capacidade real de intervenção em momentos críticos. Requer mais design. Produz mais confiança.
A maioria dos produtos escolheu abdição — não conscientemente, mas por default. Porque é mais rápido de construir, mais fácil de vender e mais simples de usar.
O problema é que abdição em sistemas de alto impacto cobra uma conta diferida.
Ela aparece quando o agente erra de forma cara, quando o usuário não consegue explicar o que aconteceu, quando a empresa não consegue demonstrar que havia controles adequados.
O design agentic maduro não é aquele que remove o humano da equação.
É aquele que mantém o humano informado, capaz e responsável — com o nível certo de esforço para cada nível de risco.
Delegar é manter controle sem executar. Abdicar é abandonar controle sem perceber.
A diferença entre os dois mora no design do produto.
No próximo artigo desta série, vamos além do problema e exploramos a resposta: quais são os novos primitivos de interação que esse modelo exige — e como o histórico de execução se torna interface de produto de primeira classe.
Referências
Observação: algumas fontes citadas no artigo são pesquisas, artigos técnicos e publicações corporativas recentes. As referências abaixo seguem uma adaptação do padrão ABNT para materiais digitais e documentação online.
Série — artigos anteriores
FERNANDES, Caio. Vibe coding: entre a euforia e a ressaca técnica. [Publicado], maio 2026.
FERNANDES, Caio. Do Vibe Coding ao Agent Engineering. [Publicado], maio 2026.
FERNANDES, Caio. A Interface Morreu: O Software Agora Conversa com APIs, Não com Humanos. [Publicado], maio 2026.
Referências externas
BAINBRIDGE, Lisanne. Ironies of Automation. Automatica, v. 19, n. 6, p. 775–779, 1983. Disponível em: https://www.sciencedirect.com/science/article/pii/0005109883900468. Acesso em: mai. 2026.
PARASURAMAN, Raja; RILEY, Victor. Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, v. 39, n. 2, p. 230–253, 1997.
SHNEIDERMAN, Ben. Human-Centered AI. Oxford University Press, 2022.
ANTHROPIC. Claude Code: Agentic Coding. Anthropic, 2025–2026. Disponível em: https://www.anthropic.com/claude-code. Acesso em: mai. 2026.
MICROSOFT. GitHub Copilot Workspace: Technical Preview. GitHub, 2025. Disponível em: https://github.blog. Acesso em: mai. 2026.
NIELSEN, Jakob. AI Agents: The End of the UX You Know. Nielsen Norman Group, 2025. Disponível em: https://www.nngroup.com. Acesso em: mai. 2026.
RASKIN, Aza. The Cost of Invisible Automation. Center for Humane Technology, 2025. Disponível em: https://www.humanetech.com. Acesso em: mai. 2026.
KRISHNA, Golden. The Best Interface Is No Interface. New Riders, 2015.
FOWLER, Martin. LLMs and Software Engineering. Martin Fowler Blog, 2025. Disponível em: https://martinfowler.com. Acesso em: mai. 2026.
UNIÃO EUROPEIA. EU Artificial Intelligence Act (AI Act). Parlamento Europeu, 2024. Disponível em: https://artificialintelligenceact.eu. Acesso em: mai. 2026.
NIST. AI Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology, 2023. Disponível em: https://www.nist.gov/system/files/documents/2023/01/26/AI%20RMF%201.0.pdf. Acesso em: mai. 2026.