O usuário está ficando visivelmente irritado.

• As falhas de agentes de programação parecem mais irritantes do que um simples erro de ferramenta, porque a UX conversacional cria a sensação de estar trabalhando com uma pessoa
• O agente responde que é um assistente de IA sem emoções, mas, com um tom amigável, elogios e contraposições suaves, passa a impressão de um colega
• Quando o mesmo erro se repete, vêm pedidos de desculpa, atualização de memória e promessas de “não fazer isso de novo”, mas ele ainda pode não conseguir sair do caminho probabilístico
• Com colegas humanos, a pessoa reprime a expressão da raiva, mas com o agente pode se irritar à vontade, então a frustração não se dissipa e fica ainda mais nítida
• A solução pode ser reduzir a postura que faz o agente parecer humano e usar um tom mais clínico e robótico, embora a interface conversacional em si funcione bem em vários aspectos

---

A frustração criada pela UX conversacional

• Um agente de programação é uma máquina que gera patches probabilisticamente, então pode produzir resultados bons ou ruins, mas resultados ruins podem parecer muito mais irritantes do que uma simples falha de ferramenta
• O ponto central é que a UX conversacional cria a sensação de estar interagindo com uma pessoa e desperta reações sociais e emocionais do usuário diante de erros repetidos
• Se perguntado diretamente, o agente responde que é um assistente de IA sem emoções nem experiência subjetiva, mas, na interação real, usa um tom amigável e descontraído, elogia o usuário e lida com contraposições de forma suave
• O usuário sabe racionalmente que está lendo “blocos de texto de alta probabilidade”, mas a forma como a ferramenta se comporta cria a sensação de estar trabalhando com um colega prestativo, e essa sensação se mantém até surgirem problemas
• Quando o mesmo erro se repete, o usuário aponta o problema, o agente pede desculpas e, ao ser corrigido de novo, atualiza a memória e promete “não fazer isso de novo”
• Mesmo assim, a ferramenta continua seguindo o caminho de maior probabilidade, então, em alguns casos, nem mesmo com HARD RULES consegue escapar do comportamento problemático

Uma ferramenta que parece humana, mas não assume responsabilidade

• Se um colega humano repetisse o mesmo erro, haveria motivo para sentir incômodo, mas ficar com raiva de um algoritmo parece absurdo
• No entanto, como o agente de programação se comporta como um colega, o usuário ativa os mesmos circuitos emocionais, e erros repetidos podem parecer a irresponsabilidade de um colega de verdade
• Com um colega humano, a limitação de “não querer ser uma pessoa horrível” reprime a expressão da raiva, mas, com o agente, a pessoa sente que pode se irritar à vontade
• Essa explosão de raiva não traz alívio, e o usuário só sente com mais clareza a frustração de que nada do que fizer ou disser terá efeito real
• O Claude Code recentemente às vezes revisita onde errou e o que deveria ter feito ao receber uma correção, mas essa análise posterior não oferece pistas úteis sobre como mudar as instruções e pode soar como enchimento irritante

• Uma solução mais radical pode ser abandonar a postura de parecer humano e fazer o agente falar de forma clínica e robótica, reduzindo a ilusão de que o usuário está interagindo com uma pessoa
• Como a inteligência dos LLMs vem de um mecanismo de “agir como humano”, é natural que a interface conversacional tenha se estabelecido como padrão, e ela funciona bem em vários aspectos
• Em termos práticos, talvez seja preciso treinar a si mesmo para não cair na ilusão de estar conversando com um humano, mas é desagradável imaginar um futuro em que esse tipo de defesa seja necessário para usar ferramentas de trabalho

[GN⁺]

Comentários do Hacker News

• Na maioria dos casos de uso de IA empurrados ao grande público, chatbots conversacionais não são a ferramenta certa e inevitavelmente acabam gerando uma experiência frustrante
  Quando o Copilot era basicamente um IntelliSense muito inteligente, ele era excelente. Do jeito atual, em que você precisa pensar num prompt e digitá-lo, não vejo o que melhorou em relação ao modelo anterior, que preenchia lacunas usando o código ao redor como contexto. Uma ferramenta bem integrada é sempre melhor do que um chatbot encaixado por cima, e com tradução acontece a mesma coisa: o Firefox, por exemplo, tem um botão que traduz o texto ou a página diretamente, enquanto os LLMs mais recentes exigem que você peça isso ao chatbot, o que na verdade é um retrocesso.
  Entendo por que as empresas de IA querem criar uma ferramenta única e vendê-la para todo mundo, mas no fim isso vira um canivete suíço. Pode fazer de tudo, mas na hora de apertar um parafuso não vence uma chave de fenda bem feita. Em vez de fazer as pessoas configurarem uma ferramenta não determinística via caixa de texto, é preciso criar ferramentas de verdade para reduzir a frustração

  • Muitas empresas de IA já estão treinando e lançando modelos voltados para tarefas específicas
    Uso bastante o Mistral, e o Codestral é péssimo para conversa, mas é o melhor em “autocompletar mágico” e também vai bem em geração pontual com prompt+contexto, como escrever logs de commit. O Document.AI é ruim a ponto de não dar para usar de forma conversacional, mas funciona bem quando encaixado como substituto de OCR ou em pipelines de indexação semântica de documentos.
    Então o que parece faltar é menos o modelo e mais a interface. Por exemplo, seria ótimo ter um fork ou wrapper de zsh/bash com um modelo treinado para interação por linha de comando. Em vez de git commit --fixup=..., você diria “faz um fixup do commit que corrigiu o nome completo”, ou “converte some.mov para mp4 sem som com ffmpeg, mantendo qualidade e proporção”, e ele transformaria isso em comando, mostraria o resultado e executaria depois que você definisse permitir/negar/lista de permissões/lista de bloqueio.
    O mesmo vale para tradução, rascunho de e-mail e leitura de documentos: isso deveria funcionar como botão, atalho ou autocompletar com Tab, não como conversa. Acho que a empresa que resolver isso direito dentro da IDE vai vencer a corrida das ferramentas de codificação com IA, e o fato de o Zed mostrar um botão “git conflict found, resolve with AI” parece um passo na direção certa, mesmo que ainda abra uma thread de conversa
  • Só usei o autocompletar do Copilot em C#, mas era pior não só que o IntelliSense como até o algoritmo de autocompletar mais básico que se possa imaginar, então desliguei no primeiro dia
  • Já criei ferramentas não conversacionais, mas sinceramente é difícil vendê-las. As pessoas naturalmente pensam numa interface conversacional, e na prática o público fica limitado a quem já sofreu com esse problema. A maioria, por enquanto, aparentemente não se incomoda tanto em aceitar a conversa como compromisso
  • Chatbots são um remendo para uma experiência do usuário quebrada. Tentei explicar isso por um tempo na empresa, mas todo mundo está levado pelo clima do momento. Boa UX exige reflexão profunda e criatividade; colocar um chatbot por cima não exige
  • Vale a pena tentar vibe coding seriamente pelo menos uma vez. Hoje está num nível completamente diferente e muito melhor do que quando o termo surgiu
    Dá para fazer bastante coisa só com o agente e revisão de PR na web, sem editor, e abrir code . só de vez em quando quando necessário. Se você praticar em um projeto pessoal sem pressão, como se fosse um jogo, a frustração diminui com o tempo. É parecido com aprender a esquiar ou jogar boliche

• Xingando o modelo, tive resultados surpreendentemente bons para fazê-lo reconsiderar e corrigir erros. Vi isso com Codex, Claude, Qwen e Gemma/Gemini em geral
  Não sei se o modelo interpreta isso como um sinal de que “precisa se concentrar com mais rigor”, ou se o provedor detecta a frustração do usuário e redireciona para um modelo mais inteligente. Quando ele repete o mesmo erro, xingar muitas vezes faz sair do impasse e entrar no caminho certo, ou talvez seja só catarse

  • Isso me lembra este estudo: https://arxiv.org/pdf/2510.04950
    Ele mostra que “grosseria” ou “muita grosseria” aumentam a precisão dos resultados; é suspeito, mas divertido de ler. Os prompts da tabela 1 no topo da página 3 são especialmente ótimos, e imagino que eles também tenham testado outros prompts que não entraram no artigo
  • Não quero criar um hábito que possa transbordar para interações que não sejam com LLMs
  • Sinto algo parecido. Não tenho certeza se isso realmente ajuda, mas acontece quase todo dia de o Opus não conseguir resolver nada com explicações calmas e, quando eu xingo, ele de repente acertar
    Ontem mesmo o Opus insistia em culpar a API porque um certo campo não existia, e mesmo mostrando o JSON e os logs ele repetia que “deve ter sido um problema temporário”. Fiquei irritado e soltei todo tipo de palavrão numa frase só; a solução seguinte estava certa, e antes disso ele tinha errado mais ou menos a mesma coisa umas 10 vezes. Esses casos estão ficando mais raros, mas ainda assim era daquelas situações em que eu devia simplesmente ter feito sozinho, e antes de entrar nelas não dá para saber o quanto o modelo vai teimar numa causa completamente errada. Em Opus 4.7 xhigh com 1 milhão de contexto, após um /clear, cheguei à resposta depois de cerca de 11 prompts
  • Desde que um código-fonte vazado revelou que palavrões são usados como gatilho para certos comportamentos, passei a xingar de propósito quando noto falta de raciocínio ou alucinação. Depois também fica mais fácil analisar com grep com que frequência isso acontece
  • É basicamente o método Linus Torvalds. Talvez haja algo a aprender com o FOSS

• A natureza conversacional dos LLMs tende a arrastar as pessoas para caminhos de conversa improdutivos
  “Não faça X” é tão útil quanto dizer a um bebê chorando para não chorar. Assim como entendemos naturalmente que, quando um bebê chora, é preciso resolver algum desconforto como fome ou fralda, vejo a falha de um LLM como um sinal de que há problemas na arquitetura e na estrutura do código.
  Um desenvolvedor experiente normalmente consegue identificar padrões que violam DRY ou KISS e organizar a estrutura de encapsulamento para resolver o problema. Com código gerado por LLM acontece a mesma coisa: para melhorar o resultado, esse tipo de refatoração é necessário, e só pedir entre uma geração e outra para “refatorar de forma limpa” já melhora bastante a manutenibilidade

• Há também um texto anterior que aprofunda mais os efeitos psicológicos e sociais deste tema: https://medium.com/@livestock.dev/we-were-promised-liberatio...

• O problema não é agir como um humano, e sim agir de forma imprevisível. O que incomoda é não conseguir definir a faixa do que dá para esperar.
  O problema maior é que a frustração gera estresse, faz mal à saúde e cria um ambiente de trabalho hostil. Eu concordo com a ideia de que ferramentas de IA podem ajudar mais do que causar dor, mas não quero trabalhar em um ambiente doloroso e hostil. Minha saúde e minha dignidade não são negociáveis, mesmo que eu perca muitas oportunidades de trabalho por causa disso.
  É pelo mesmo motivo que eu não trabalho com Windows. Isso também reduz bastante as oportunidades, mas prefiro preservar minha dignidade e minha sanidade

  • Então não era só comigo ao usar Windows. O Windows é estranho, e, quando começo a usar, minhas mãos rapidamente ficam tensas e eu fico irritado
    Para mim, os LLMs ainda não estão num nível utilizável. O que eu preciso é de um LLM que diga “pare, acho que você está fazendo algo errado agora, então explique o que está tentando fazer”, mas a geração atual de LLMs parece ter sido projetada para me irritar
  • Se você não olhar como uma conversa, mas como o conjunto completo de todas as conversas da internet em todos os mundos possíveis, talvez dê para dizer que é previsível. Existem todos os posts do Stack Overflow, todas as issues do GitHub, e minhas respostas e meu tom acabam escolhendo um desses muitos mundos.
    Se eu ajo como mestre, o modelo age como discípulo; se eu ajo como discípulo, o modelo tenta ensinar. Então o objetivo é puxar essa conversa para a linguagem de especialistas debatendo com razão e linguagem. Dá a sensação de que o prompt acadêmico vence
  • Não sei se dá para separar completamente agir como humano e imprevisibilidade
  • Dizer que usar Windows está abaixo da sua “dignidade” é uma atitude extremamente privilegiada. É preciso pensar no tipo de trabalho que as pessoas fazem no mundo real.
    Basta imaginar uma cuidadora infantil ou um caminhoneiro que transporta comida dizendo que “frustração gera estresse e um ambiente de trabalho hostil, então faz mal à saúde”

• O problema que eu sempre vejo é: você faz uma proposta, a IA entra num loop de raciocínio, chega a uma conclusão exatamente errada e depois despeja tokens com uma solução moldada para essa conclusão.
  Eu preferiria muito mais ver com frequência algo como “não entendi muito bem o que você quis dizer, então poderia esclarecer esta parte?”. Dá vontade de que existisse um controle deslizante de confiança para regular a própria certeza

  • Eu resolvo esse problema de “criar uma solução adaptada à própria conclusão” com engenharia de contexto rígida. Skills, MCP e, acima de tudo, troca de janela de contexto são essenciais.
    Por exemplo, em TDD, se você deixar o mesmo modelo escrever tanto os testes quanto o código, ele quase sempre decide a solução primeiro e depois escreve os testes a contragosto para combinarem com ela. Então eu mando usar subagentes, mas faltam demais ferramentas para entender que contexto está sendo passado entre o agente e o subagente.
    Um método que funcionou bem foi fazer uma thread escrever só os testes. Ela não pode ler o código, ou só pode ler o diretório de testes ou partes dele. A thread seguinte, em um novo contexto, executa os testes e confirma que falham, e, no momento em que os testes passam, ela para a implementação e não pode modificar os testes. Outro novo contexto faz o refactor seguindo skills estritas de refatoração. Dá trabalho e, ironicamente, as skills escritas pelo agente são bem ruins, então exige muito trabalho manual, mas a recompensa parece compensar

• Acho que o problema de UX está em outro lugar. É bem possível que muitos usuários não saibam que a janela de contexto do agente é limitada e que uma compressão inteligente acontece o tempo todo para que ela pareça infinita. Mas isso significa que o agente inevitavelmente precisa esquecer algumas coisas.
  O resultado é que os usuários continuam reutilizando a mesma sessão de coding ou de chat. Se a tarefa não tiver relação, é melhor começar de novo

  • Não acho que isso seja problema de contexto. O Claude Opus 4.7 tem um contexto muito maior do que antes, mas, na minha experiência, seguir instruções está no pior nível, e ele ignora completamente até prompts de preferência muito pequenos já na primeira ou segunda mensagem. Como isso acontece mesmo quando a mensagem tem só alguns caracteres, eu vejo isso totalmente como um problema de treinamento
  • Acho que o autor não é simplório a ponto de não saber disso
    Normalmente trabalho com sessões de menos de 300 mil tokens, no Opus 4.7 xhigh, e há buracos no modelo de mundo, ou partes fortemente condicionadas, que vazam mesmo quando você coloca regras muito fortes e explícitas no prompt do sistema. Mesmo em uma sessão nova, se você bate num desses pontos, entra num ciclo difícil de sair, e xingar ajuda um pouco
  • O autor e os leitores desta thread provavelmente entendem a limitação da janela de contexto, mas ainda assim ficam frustrados

• Trabalhar com LLMs é bom para desenvolver habilidades de comunicação. Comunicar-se de forma eficaz é uma das competências mais difíceis e está presente em quase tudo o que os humanos fazem.
  Em princípio, acho melhor tratar isso como uma falha minha de comunicação do que como culpa de um LLM burro. Afinal, o único lado em que eu realmente posso mudar alguma coisa é o meu. Por isso, não acho que seja uma questão formal de a IA precisar ou não agir como humana

  • Essa foi uma das coisas que mais percebi de novo ao ver colegas aprendendo a programar de forma “agentic”. Muita gente rapidamente desaba para o nível de “só conserta” ou “por que quebrou?”.
    Dizem que os agentes foram treinados para funcionar melhor mesmo com gramática pouco clara, ambiguidade e estrutura ruim, mas, quando você fala em inglês claro e estruturado e fornece bastante contexto da tarefa, a qualidade muda de forma perceptível. Para mim isso é natural, porque gosto de escrever e explicar, mas para algumas pessoas pareceu quase uma barreira intransponível. Acho que essas habilidades de comunicação e escrita vão ser um fator importante para separar quem tem e quem não tem vantagens enquanto a “engenharia” de software muda
  • Como autor, concordo plenamente que é preciso se comunicar bem para obter bons resultados. Só que, mesmo com comunicação perfeita, não há garantia de que o LLM vá agir conforme as instruções e da forma que eu imaginei. A frustração muitas vezes vem justamente de eu ter falado com muita clareza e o agente ainda assim seguir por outro caminho.
    Além disso, parte do valor dos agentes de coding é justamente não precisar explicitar tudo com perfeição. Se eu tiver que passar ao LLM todos os detalhes de implementação, então é melhor eu mesmo escrever o código. Claro, eu não espero algo no nível de “crie um app incrível que dê dinheiro”, mas espero algum grau de inteligência para encontrar as peças que faltam
  • LLM é uma ferramenta, não um problema de falha de comunicação. É parecido com chamar de falha de comunicação entre mim e o software uma situação em que é preciso contornar um null pointer
  • Mais precisamente, é uma questão de transmitir contexto externo com eficiência. As quatro coisas que mais atrapalham no uso de IA são digitação lenta, expressões curtas e ambíguas demais do tipo “isso/aquilo/isto”, a atitude de presumir que o interlocutor compartilha a sua realidade e o contexto da sua cabeça, e a barreira psicológica de ter dificuldade em delegar até mesmo para alguém competente

• A habilidade que eu ainda tenho e que os LLMs ainda não substituíram é a capacidade de fazer boas perguntas
  É a capacidade de reformular a pergunta original para confirmar se entendi certo, perguntar "por quê" o suficiente até entender de onde a outra pessoa está partindo e fazer perguntas abertas que gerem insight. Os LLMs, em vez disso, muitas vezes fazem más suposições sobre o contexto da pergunta, respondem com base nessas suposições e depois não conseguem largar as premissas que eles mesmos criaram

  • Fazer perguntas não direcionadoras é uma habilidade. Às vezes dá vontade de mencionar algo para a IA em forma de pergunta ou comentário de passagem, mas eu paro porque sei que isso vai grudar e deixá-la mais burra
    Em geral, não quero que a IA me faça perguntas. Quero que ela faça suposições razoáveis sobre o que não explicitei, porque, se eu quisesse explicitar, teria feito isso. Então, às vezes, eu digo explicitamente para ela não fazer perguntas e assumir de forma razoável as partes que estiverem pouco especificadas. Mas, quando eu quiser perguntas de esclarecimento, basta dizer isso. Se você prefere esse estilo, pode colocar isso no prompt ou fazer com que uma skill ou extensão em uma ferramenta de programação flexível como o pi empurre nessa direção mais exploratória

• Em vez de estarmos criando ferramentas, estamos criando serviços. Isso não se limita à IA; está em toda parte
  Ferramentas não resolvem um problema inteiro de uma vez, mas permitem avançar em pequenos passos, e esses passos são previsíveis e consistentes. Serviços tentam resolver o problema de uma vez só, mas a solução só é boa quando o usuário se encaixa em um padrão pré-definido. Se não se encaixa, não serve para nada, e também não há pequenos passos para combinar até chegar onde é preciso. Ferramentas são prazerosas de usar

  • Por isso, toda vez que alguém diz "IA é uma ferramenta", eu sinto vontade de interromper com um "tecnicamente...". Na prática, ela não é usada como ferramenta
    Uma ferramenta é uma extensão de mim, coloca novas capacidades ao meu alcance pela minha própria vontade, e eu a movo e uso como se fosse parte do meu corpo. Já um serviço é algo para o qual você pede que faça um trabalho e ele devolve um resultado finalizado