Pensamento de Produto

Taste acima de prompts: a verdadeira habilidade por trás de ótimos produtos de IA

Todo mundo está aprendendo engenharia de prompts. Mas o verdadeiro diferencial não é como você fala com o modelo, é saber o que construir e o que deixar de fora. A lacuna entre 'tecnicamente funciona' e 'encanta usuários' é taste.

ASR

Apollo Space Research

Apollo Space

· 14 min de leitura

A Notificação Que Ninguém Pediu

Nosso agent de conteúdo costumava ser verboso. Ele terminava de analisar um blog post de um concorrente e produzia um relatório assim:

Análise de Concorrente: Acme Corp Blog Update

  • Novo post publicado: “5 Formas de Melhorar Seu Pipeline de Vendas” (1 de março de 2026)
  • Contagem de palavras: 2.340 palavras
  • Nível de leitura: Grade 8.2
  • Densidade de palavras-chave: “pipeline de vendas” (2,3%), “CRM” (1,8%), “automação” (1,4%)
  • Potencial estimado de tráfego orgânico: 2.400-3.800 visitas mensais
  • Compartilhamentos sociais no momento da análise: LinkedIn (34), Twitter (12)
  • Autora: Sarah Chen, VP Marketing
  • Sentimento: Positivo/Educacional
  • Tópicos cobertos: gestão de pipeline, higiene de CRM, cadência de follow-up, lead scoring, ferramentas de automação
  • Posicionamento competitivo: Não menciona nossa categoria diretamente
  • Ação recomendada: Considerar criar uma peça de resposta direcionando palavras-chave similares com ângulo de diferenciação

Cada dado era preciso. Cada métrica era real. A ação recomendada era razoável. E absolutamente ninguém lia além da terceira linha.

Sabemos disso porque rastreamos esse tipo de output. Relatórios verbosos como esse tendem a ter taxas de leitura completa na casa dos dez e poucos por cento. Na maior parte das vezes, a pessoa recebendo o relatório olha o título e segue em frente. O agent estava produzindo output correto que era funcionalmente inútil.

A solução não foi um prompt melhor. A solução foi taste.

Reescrevemos o output do agent para ficar assim:

Acme publicou sobre pipelines de vendas. Conteúdo padrão, nada diferenciado. Sem menção a agents de IA. Nosso posicionamento está seguro. Nenhuma ação necessária.

A taxa de leitura completa dispara. Mesma análise subjacente. Mesmos dados. Apresentação radicalmente diferente, porque alguém (dolorosamente, ao longo de várias iterações) tomou decisões de julgamento sobre o que importava e o que não.

Isso é taste. E nenhum curso de engenharia de prompts ensina.

O Complexo Industrial da Engenharia de Prompts

Vale dizer algo impopular: engenharia de prompts é superestimada.

Não inútil, superestimada. A lacuna entre o engenheiro de prompts mediano e o top-1% é real mas está diminuindo. Modelos estão ficando melhores em interpretar prompts medianos. Ferramentas de otimização de prompts estão automatizando as partes mecânicas. A vida útil de uma técnica específica de prompting é medida em meses antes da próxima versão do modelo torná-la desnecessária.

Em 2024, “chain of thought” era uma revelação. Em 2025, modelos fazem isso por padrão. Em 2024, “few-shot examples” eram uma habilidade crítica. Em 2025, modelos precisam de menos exemplos para generalizar. A habilidade técnica de estruturar prompts está numa esteira que continua acelerando.

Enquanto isso, o panorama de produtos de IA está afogado em produtos tecnicamente competentes e esteticamente mortos. Ferramentas que funcionam corretamente mas parecem erradas. Agents que produzem output preciso que ninguém lê. Dashboards que mostram cada métrica porque ninguém teve a coragem de escolher quais três importam.

Cursos de “engenharia de prompts” se multiplicaram nas plataformas de ensino online. Perfis profissionais aos milhares passaram a listar “engenharia de prompts” como habilidade. Os guias de prompting dos principais laboratórios de IA estão entre os conteúdos técnicos mais consumidos da internet.

Ninguém está ensinando taste.

O Que Taste Significa em Produtos de IA

Taste não é preferência subjetiva disfarçada de habilidade. É uma forma específica de julgamento que se manifesta em decisões concretas:

Saber o que deixar de fora. Cada informação que um agent apresenta é uma decisão que está forçando sobre o usuário. “Seu concorrente publicou um blog post” força o usuário a decidir: isso é importante? “Seu concorrente publicou sobre um tópico competindo diretamente com sua página principal de produto” é uma decisão que o agent já tomou, apresentando apenas o que requer atenção humana.

Deixar coisas de fora é mais difícil que incluí-las. Incluir tudo é a escolha segura, ninguém pode te culpar por mostrar demais. Deixar de fora requer confiança de que seu julgamento sobre o que importa está correto. Essa confiança vem de entender seu usuário profundamente, não de engenheirar um prompt melhor.

Saber quando ficar quieto. Os piores produtos de IA são os mais barulhentos. Eles notificam sobre tudo porque não conseguem distinguir sinal de ruído. Cada notificação tem peso igual porque o produto não tem opinião sobre o que é importante.

O agent de meeting digest da Apollo Space processa cada reunião. Mas não envia um relatório para cada reunião. Se uma reunião consistiu de atualizações de status rotineiras sem decisões tomadas, sem action items gerados e sem desacordos significativos, o agent fica quieto. Nada aconteceu que requeira atenção. A ausência de uma notificação é em si um sinal: “Esta reunião foi rotineira. Você não precisa pensar sobre ela.”

Construir isso exigiu que definíssemos como é “nada notável”, uma decisão de julgamento que nenhum prompt pode tomar porque depende do contexto organizacional, dos papéis dos participantes e das prioridades atuais do negócio.

Saber a resolução certa. Quanto detalhe um agent deveria fornecer? A resposta é: depende. Um brief de deal intelligence para um prospect de $5K deveria ser um parágrafo. Um brief para um prospect de $500K deveria ser uma página. Um brief para um prospect de $5M deveria ser um dossiê abrangente.

Essa é uma decisão de taste, não técnica. O agent poderia produzir o mesmo nível de detalhe para cada prospect. Escolher escalar detalhe com risco é uma decisão de produto que reflete entendimento de como o time de vendas realmente trabalha.

Saber o tom certo. Um agent escalando uma pergunta rotineira deveria ser casual. Um agent flaggando uma vulnerabilidade potencial de segurança deveria ser urgente. Um agent entregando boas notícias deveria ser conciso (ninguém precisa de explicação detalhada de por que as coisas foram bem). Um agent entregando más notícias deveria fornecer contexto (pessoas precisam entender o que deu errado e o que fazer a respeito).

Tom em produtos de IA não é sobre fazer o agent “parecer humano.” É sobre combinar o estilo de comunicação com o contexto. Um alerta de segurança entregue num tom descontraído e conversacional é chocante. Uma atualização de status rotineira entregue com urgência e gravidade é exaustiva.

A Reescrita do Agent de Conteúdo

Vale detalhar as decisões específicas de taste que tomamos ao reconstruir o agent de conteúdo da Apollo Space. Não os prompts, as decisões de produto.

Decisão 1: Relatórios devem ter um veredito, não apenas dados.

A primeira versão do agent de conteúdo apresentava dados e deixava o usuário decidir o que significavam. Esse é o instinto padrão de engenheiros: dê às pessoas a informação bruta e deixe tirarem conclusões.

Mas não é isso que operadores ocupados precisam. Eles precisam de uma conclusão. “Concorrente X publicou algo interessante” ou “Concorrente X publicou algo irrelevante.” O veredito pode estar errado às vezes, é para isso que servem os feedback loops. Mas um veredito errado que pode ser corrigido é mais valioso que dados precisos que requerem interpretação.

Mudamos a estrutura de output do agent de conteúdo de Dados -> Análise -> Recomendação para Veredito -> Evidência de suporte (se necessário) -> Ação recomendada (se houver).

O veredito vem primeiro. Se o usuário concorda, terminou em 5 segundos. Se quer verificar, a evidência de suporte está lá. Se discorda, fornece feedback que melhora vereditos futuros.

Decisão 2: Descobertas negativas são mais valiosas que positivas.

A primeira versão reportava tudo: novos blog posts, atualizações de redes sociais, mudanças de preço, vagas de emprego, anúncios de produto. Peso igual para tudo.

Mas na prática, certas descobertas são desproporcionalmente acionáveis. Um concorrente cortando preços é urgente. Um concorrente publicando um blog post geralmente não é. Um concorrente postando vaga para “VP de IA” é interessante. Um concorrente postando vaga para “Designer Júnior” é ruído.

Construímos um filtro de significância baseado em impacto competitivo. O agent avalia cada descoberta contra a pergunta: “Um estrategista competitivo inteligente se importaria com isso?” Se a resposta provavelmente é não, a descoberta é registrada mas não apresentada. O usuário pode acessar o log completo se quiser, mas sua visão padrão mostra apenas descobertas significativas.

Isso exigiu que definíssemos “significativo,” que é uma decisão de taste. Erramos várias vezes. Versões iniciais filtravam agressivamente demais (deixavam passar o pivot de um concorrente para o próprio mercado). Versões posteriores filtravam frouxamente demais (apresentavam cada post de rede social). A calibração atual é resultado de meses de feedback loops e iteração.

Decisão 3: O agent deveria se adaptar ao padrão de consumo do usuário.

Alguns usuários leem cada relatório em detalhe. Outros passam os olhos por títulos. Outros só engajam quando algo é flaggado como alta prioridade. O agent de conteúdo deveria adaptar seu formato de output ao padrão de cada usuário.

Para usuários detalhistas: relatórios completos com dados de suporte. Para quem passa os olhos: resumos em bullet points com vereditos em negrito. Para usuários somente-prioridade: silêncio a menos que algo seja genuinamente importante, depois um alerta conciso.

Isso não foi um desafio de engenharia de prompts. Foi um desafio de design de produto. Tivemos que construir rastreamento de comportamento do usuário, definir arquétipos de consumo e projetar três formatos diferentes de output, depois deixar o agent aprender qual formato cada usuário prefere baseado em padrões de engajamento.

O prompt para gerar o relatório mal mudou. O produto ao redor do prompt mudou completamente.

Por Que Taste Não Pode Ser Automatizado

Aqui está a verdade desconfortável para a multidão do “IA vai automatizar tudo”: taste é especificamente a coisa que não pode ser automatizada.

Você pode automatizar otimização de prompts. Pode automatizar testes A/B de formatos de output. Pode automatizar coleta e análise de métricas. Mas não pode automatizar a decisão sobre quais métricas importam. Não pode automatizar o julgamento sobre quando um agent deveria falar e quando deveria ficar quieto. Não pode automatizar a sensação de “isso parece errado” que te leva a redesenhar um padrão de interação mesmo que os dados digam que está funcionando.

Taste é o produto de experiência acumulada, empatia por usuários e a disposição de ter opiniões fortes sobre como é algo bom. É Steve Jobs decidindo que o iPod deveria ter um botão quando todo concorrente tinha doze. É Dieter Rams decidindo que um rádio deveria parecer mobília, não tecnologia. É o time do Basecamp decidindo que sua ferramenta de gerenciamento de projetos deveria fazer menos que todo concorrente, não mais.

Em produtos de IA, taste se manifesta como a coragem de fazer seu agent fazer menos. De filtrar mais agressivamente. De ficar quieto mais frequentemente. De apresentar um veredito em vez de um dump de dados. De projetar para a atenção do usuário como recurso escasso, não infinito.

Todo produto de IA medíocre que já experimentamos falha da mesma forma: faz tudo que o modelo é capaz, em vez do subconjunto que o usuário realmente precisa. A capacidade técnica é impressionante. A experiência do produto é exaustiva.

O Stack de Taste

Se fôssemos formalizar taste num processo de desenvolvimento (o que meio que derrota o propósito, mas acompanhe), seria assim:

Camada 1: Entenda o trabalho real do usuário. Não o cargo. O workflow diário real. O que a diretora de vendas olha primeiro de manhã? Com o que ela se preocupa? De que informação ela já tem demais? Que informação ela gostaria que alguém simplesmente contasse?

Isso é pesquisa etnográfica, não user stories. Requer observar pessoas trabalhando, não perguntar o que querem. Pessoas não conseguem articular o que precisam de um produto que ainda não existe. Mas você pode observar o que as frustra nos workflows atuais e inferir o que um produto ideal eliminaria.

Camada 2: Defina o papel do agent na vida do usuário. Este agent é um consultor de confiança que proativamente apresenta insights? Um assistente confiável que lida com tarefas rotineiras? Um especialista consultado para decisões específicas? O papel determina tudo: frequência de comunicação, nível de detalhe, tom, nível de iniciativa.

Um consultor fala sem ser perguntado com opiniões. Um assistente responde a pedidos e reporta conclusão de tarefas. Um especialista espera ser consultado e fornece análise profunda. A maioria dos produtos de IA não faz essa escolha, tentam ser os três simultaneamente, o que é exaustivo para o usuário e confuso para o agent.

Camada 3: Projete a hierarquia de informação. Nem todos os outputs são iguais. Defina o que é crítico (interrompe o usuário imediatamente), importante (incluído no próximo relatório agendado), notável (registrado para referência) e ignorável (filtrado inteiramente). Essa hierarquia reflete sua opinião sobre o que importa, e ter essa opinião é a essência do taste.

Camada 4: Itere no feeling. Esta é a parte que não pode ser sistematizada. Use o produto. Use-o todos os dias. Note o que te irrita, o que te surpreende, o que gostaria que fosse diferente. Faça mudanças baseadas nessas observações. Use de novo. O feedback loop entre usar o produto e melhorar o produto é onde taste se desenvolve.

Usamos os agents da Apollo Space diariamente. Não como demo. Como nosso workflow real. Quando o agent de meeting digest envia algo que não interessa, sentimos como usuários, não como construtores. Esse sentimento, a micro-frustração de informação indesejada, impulsiona mudanças de produto que nenhuma métrica revelaria.

O Moat Que Você Não Consegue Copiar

Há um argumento estratégico para taste que vai além da experiência do usuário: taste é um moat.

Prompts podem ser copiados. Arquitetura pode ser engenharia reversa. Features podem ser replicadas. Mas taste, o julgamento acumulado de produto que resulta em centenas de pequenas decisões sobre o que incluir, excluir, enfatizar e desenfatizar, não pode ser copiado porque não é uma coisa. É o resíduo de milhares de horas usando, observando e iterando num produto.

Um concorrente pode ver que o agent de conteúdo da Apollo Space entrega vereditos em vez de dumps de dados. Pode copiar essa feature. Mas não pode copiar a calibração do que constitui uma descoberta “significativa,” porque essa calibração é produto de meses de feedback de usuários reais em workflows reais. Pode copiar os três formatos de output (detalhado, resumo, somente-prioridade), mas não pode copiar a lógica que atribui cada usuário ao formato certo, porque essa lógica incorpora nosso entendimento de como diferentes operadores consomem informação.

Cada decisão de taste é individualmente pequena e coletivamente irreproduzível. É o que separa os produtos que as pessoas toleram dos produtos que as pessoas amam.

A Lacuna Está Aumentando

Aqui está a nossa aposta: à medida que modelos de IA melhoram, a lacuna técnica entre produtos de IA vai diminuir e a lacuna de taste vai aumentar.

Quando modelos eram primitivos, habilidade técnica era o diferencial. Fazer o GPT-3 produzir output útil exigia expertise genuína em engenharia de prompts. Os melhores produtos de IA em 2022-2023 eram os com os melhores engenheiros.

À medida que modelos se tornam mais capazes, e estão se tornando mais capazes rapidamente, o retorno marginal da otimização técnica diminui. A diferença entre um bom prompt e um ótimo prompt no GPT-4 era significativa. A mesma diferença em modelos de 2026 é menor. Os modelos estão preenchendo as lacunas que humanos costumavam engenheirar.

O que resta quando a lacuna técnica fecha? Julgamento de produto. As decisões sobre o que construir, como apresentar, quando revelar e quando ficar quieto. As decisões que requerem entender humanos, não entender modelos.

O panorama de produtos de IA está prestes a bifurcar. De um lado: produtos tecnicamente competentes que parecem planilhas com chatbots, precisos, completos, exaustivos. Do outro lado: produtos com taste que parecem ter sido projetados por alguém que realmente os usa, opinativos, seletivos, deliciosos.

A primeira categoria vai competir em preço e features. A segunda vai competir em amor.

Sabemos de qual lado queremos que a Apollo Space esteja. E sabemos que chegar lá não é questão de engenheirar prompts melhores. É questão de tomar melhores decisões sobre o que nossos agents devem e não devem fazer, e ter a convicção de shipar essas decisões mesmo quando os dados são ambíguos e a opção segura é incluir tudo.

Taste acima de prompts. Sempre.

Acompanhe nosso product thinking, substância acima de hype

Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.

Entrar na lista de espera