Artigos
O teto no uso de IA é a sua ambição: velocidade, altura, profundidade e amplitude
Felix Rieseberg, líder de engenharia da Anthropic, divide "ter mais ambição com a IA" em quatro dimensões: velocidade, altura, profundidade e amplitude. Este artigo resume o método e os exemplos dele e acrescenta minhas anotações de prática: dar instruções orientadas a objetivos e coordenar um time de especialistas Multi-AI Agents para uma revisão cruzada com vários pontos de vista, elevando a qualidade das tarefas.
· 7 min de leitura
Felix Rieseberg, líder de engenharia da Anthropic, escreve em "How to be more ambitious: A tutorial for humans with models" que, quando vê alguém conseguir resultados impressionantes com IA, ele e as pessoas ao redor costumam ter a mesma reação: "Não estamos sendo ambiciosos o bastante."
Minha leitura: o limite do que as pessoas tiram da IA muitas vezes está na própria ambição e imaginação, e não no modelo.
Ele divide a "ambição" em quatro dimensões:
- Velocidade (Speed): fazer o mesmo trabalho em menos tempo.
- Altura (Altitude): subir o nível de abstração e olhar para o resultado final, e não para uma tarefa isolada.
- Profundidade (Depth): trabalhar com os padrões, as ferramentas e os métodos dos melhores especialistas da área.
- Amplitude (Range): sair de uma única área e buscar soluções entre várias disciplinas.
A conclusão primeiro: dê instruções precisas, orientadas a objetivos, e coordene um time de especialistas Multi-AI Agents para colaboração e revisão cruzada com vários pontos de vista; é assim que a qualidade das tarefas sobe como um todo.
I. Velocidade: a mais básica e a que menos trava#
Fazer o mesmo trabalho em menos tempo. Felix considera que todo mundo já conhece bem esse ponto, então o artigo passa direto por ele.
Minha opinião: velocidade é o valor mais intuitivo da IA, mas se você só busca velocidade, a forma de colaborar não muda muito. O que realmente faz diferença são as outras três dimensões.
II. Altura: perguntar pelo "objetivo por trás do objetivo"#
A pergunta central: qual é, de fato, o resultado que quero em seguida? Qual é o objetivo por trás do meu objetivo?
Os exemplos de Felix:
- De corrigir um crash a fazer o app parar de ter crashes. Ele começou pedindo ao Claude que corrigisse um único crash e depois passou a exigir que o app se mantivesse com zero crashes. Para isso rodar de forma contínua e automática, ele primeiro precisou mudar o próprio processo: deixar os relatórios de crash fáceis de acessar, associar as versões do app aos commits do Git e permitir que o Claude usasse máquinas Windows, macOS e Linux para reproduzir e verificar as correções.
- Uma escalada em três passos para a revisão trimestral de negócios (QBR):
- Partir, sempre que possível, dos dados brutos para explicar o que mudou neste trimestre, por quê e o que fazer em seguida.
- Identificar as 3 decisões mais urgentes, escrevendo para cada uma os argumentos a favor e contra.
- Projetar um mecanismo alternativo que detecte problemas mais cedo do que a apresentação trimestral, testá-lo com dados históricos e depois rodá-lo em paralelo com o processo atual durante um trimestre.
Ele também lembra um limite: em 2026, uma meta vaga como "Claude, vá ganhar dinheiro para mim" ainda não funciona, mas ele espera que o nível de abstração que os modelos conseguem tratar continue subindo.
III. Profundidade: exigir o padrão dos melhores especialistas da área#
O método de Felix:
- Usar as ferramentas que esse setor realmente usa. O modelo muitas vezes só troca o vocabulário sem trocar o método, e se livra da tarefa com uma tabela em Markdown. Insista em ferramentas de análise de verdade, como bancos de dados e modelos estatísticos.
- Definir uma meta aparentemente absurda e dizer ao modelo que ela tem solução. O exemplo dele: depois de reduzir o carregamento de um site de 10 segundos para 5 segundos, pedir 200 milissegundos. Quando o modelo recua, manter que a meta é alcançável.
- Desafiar as hipóteses em que você acredita. Dê ao modelo os dados brutos e peça que ele os examine de forma adversarial. Por exemplo: "Achamos que o abandono é culpa do onboarding; tente reproduzir essa conclusão a partir dos dados brutos."
- Gerar conhecimento novo. Montar uma simulação a partir dos logs, encontrar o sinal de abandono mais precoce que você ainda não conhecia e depois validá-lo com dados nunca vistos.
- Buscar um juiz externo (Outside Judge). Não deixe o modelo corrigir a si mesmo. O ideal é conectar uma ferramenta que o modelo possa executar diretamente e que dê retorno imediato para validar o resultado.
A regra dele para prompts: o que se quer é uma "versão mais profunda", não uma "versão maior". Peça ao modelo que diga o que os melhores profissionais fariam a mais, onde estão os dados mais brutos, quais métodos e ferramentas usar e o que, além do modelo ou do seu próprio julgamento, pode provar que o resultado está certo.
IV. Amplitude: verbos em vez de substantivos e montar um time de especialistas#
- Verbos em vez de substantivos. Felix tira esse conceito de "The Art of Innovation". Em vez de "uma apresentação", o QBR vira "fazer pessoas muito ocupadas entenderem causas e efeitos em 30 minutos e decidirem em meio à incerteza". Definir a meta com um verbo permite enxergar que habilidades de quais áreas são necessárias.
- Montar um time. Para fazer uma boa apresentação, são necessários analistas, jornalistas e editores; para apresentá-la no palco, some um designer de animação e de som. Para a revisão adversarial, chame pesquisadores de um fundo vendido (short seller) e contadores forenses.
- Sem encenação sem sentido. Não se trata de dizer ao modelo "escreva no tom de um fundo vendido", mas de pedir que ele execute de fato um dos métodos de pesquisa desse tipo de fundo. Mudar só o tom não melhora o resultado.
O pré-requisito: o modelo precisa de um computador onde possa instalar software e de acesso aos dados relevantes, por exemplo por meio de conectores MCP.
V. Minhas anotações de prática: da "transferência de dados" à "realização da intenção"#
O que vem a seguir é a minha extensão, a partir de arquitetura de software e da prática de engenharia; não é conteúdo do artigo original.
1. Jobs to be Done e orientação por intenção (Intent-Based)#
- Não pergunte "o que fazer", pergunte "o que alcançar". O design não deve parar em um pipeline passivo de transferência de dados como
generate_deck_pdf(), e sim subir para a intenção de uma transição de estado como resolve_leadership_uncertainty_and_commit_budget().
- Defina uma função de perda de verdade. Se você só pede um entregável, o modelo produz enrolação que parece perfeita; se pede que ele resolva a incerteza da decisão, o modelo e o Sub-agent tapam por conta própria as lacunas lógicas e os limites de risco.
2. Divergir ao explorar, convergir ao validar#
- Ao explorar, primeiro se diverge para achar possibilidades e depois se converge.
- Ao validar, não se diverge mais. Evite perguntas sem fronteiras como "de que outras formas dá para fazer isso?", que só trazem generalidades.
- Escreva explicitamente o escopo da meta, as restrições e as ferramentas de verificação objetivas (um script de teste específico, um limite para indicadores de negócio), para que o time Multi-Agent faça os testes de estresse em um quadro focado e entregue um trabalho de alta qualidade.
Resumo das anotações#
- Orientação a objetivos: verbos em vez de substantivos. Entregar um resultado que resolve o problema, e não apenas um produto para cumprir tabela.
- Exploração e convergência: ao explorar, divergir para achar possibilidades; ao validar, convergir de forma estrita e verificar os limites.
- Foco na abstração: partir da pergunta central e reconstruir todo o fluxo da tarefa.
- Profundidade de especialista: não imitar só o tom dos especialistas, mas obrigar o modelo a resolver o problema com as ferramentas e os métodos dos melhores.
Artigo original: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)