Artigos
O teto no uso de IA é a sua ambição: velocidade, altura, profundidade e amplitude
Felix Rieseberg, responsável de engenharia da Anthropic, decompõe «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 as minhas notas de prática: dar instruções orientadas a objetivos e coordenar uma equipa de especialistas Multi-AI Agents para uma revisão cruzada de vários ângulos, de modo a melhorar a qualidade das tarefas.
· 7 min de leitura
Felix Rieseberg, responsável de engenharia da Anthropic, escreve em «How to be more ambitious: A tutorial for humans with models» que, quando vê alguém obter resultados impressionantes com IA, ele e as pessoas à sua volta têm muitas vezes a mesma reação: «Não somos ambiciosos o suficiente.»
A minha leitura: o limite do que as pessoas conseguem tirar da IA está muitas vezes na própria ambição e imaginação, e não no modelo.
Ele decompõe 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 procurar soluções entre várias disciplinas.
A conclusão primeiro: dê instruções precisas, orientadas a objetivos, e coordene uma equipa de especialistas Multi-AI Agents para colaboração e revisão cruzada de vários ângulos; é assim que a qualidade das tarefas sobe de forma global.
I. Velocidade: a mais básica e a que menos bloqueia#
Fazer o mesmo trabalho em menos tempo. Felix considera que este ponto já é bem conhecido de todos, por isso o artigo passa-o à frente.
A minha opinião: a velocidade é o valor mais intuitivo da IA, mas se só se procura velocidade, a forma de colaborar não muda muito. O que realmente faz a diferença são as outras três dimensões.
II. Altura: perguntar pelo «objetivo por trás do objetivo»#
A pergunta central: qual é realmente o resultado que quero a seguir? Qual é o objetivo por trás do meu objetivo?
Os exemplos de Felix:
- De corrigir um crash a fazer com que a aplicação deixe de ter crashes. Ele começou por pedir ao Claude que corrigisse um único crash e depois passou a exigir que a aplicação se mantivesse com zero crashes. Para que isto corresse de forma contínua e automática, teve primeiro de mudar o seu próprio processo: tornar os relatórios de crash fáceis de obter, associar as versões da aplicação 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ócio (QBR):
- Partir, sempre que possível, dos dados brutos para explicar o que mudou neste trimestre, porquê e o que fazer a seguir.
- Identificar as 3 decisões mais urgentes, escrevendo para cada uma os argumentos a favor e contra.
- Desenhar um mecanismo alternativo que detete problemas mais cedo do que a apresentação trimestral, testá-lo com dados históricos e depois executá-lo em paralelo com o processo atual durante um trimestre.
Ele também lembra um limite: em 2026, um objetivo vago como «Claude, vai ganhar dinheiro por mim» ainda não funciona, mas espera que o nível de abstração que os modelos conseguem tratar continue a subir.
III. Profundidade: exigir o nível 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 despacha com uma tabela em Markdown. Insista em ferramentas de análise a sério, como bases de dados e modelos estatísticos.
- Definir um objetivo aparentemente irrazoável e dizer ao modelo que é resolúvel. 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 o objetivo é alcançável.
- Desafiar os pressupostos em que acredita. Dê ao modelo os dados brutos e peça-lhe que os examine de forma adversarial. Por exemplo: «Achamos que o abandono se deve ao onboarding; tenta reproduzir esta conclusão a partir dos dados brutos.»
- Gerar conhecimento novo. Construir uma simulação a partir dos logs, encontrar o sinal de abandono mais precoce que ainda não conhecia e depois validá-lo com dados nunca vistos.
- Procurar um juiz externo (Outside Judge). Não deixe o modelo corrigir-se a si próprio. O ideal é ligar uma ferramenta que o modelo possa executar diretamente e que dê feedback imediato para validar o resultado.
A sua regra 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, que métodos e ferramentas usar, e o que, além do modelo ou do seu próprio juízo, pode provar que o resultado está certo.
IV. Amplitude: verbos em vez de substantivos e montar uma equipa de especialistas#
- Verbos em vez de substantivos. Felix retira este conceito de «The Art of Innovation». Em vez de «uma apresentação», o QBR passa a ser «fazer com que pessoas muito ocupadas percebam as causas e os efeitos em 30 minutos e decidam em condições de incerteza». Definir o objetivo com um verbo permite ver que competências de que áreas são necessárias.
- Montar uma equipa. Para fazer uma boa apresentação, são precisos analistas, jornalistas e editores; para a apresentar em palco, junte-se um designer de animação e de som. Para a revisão adversarial, recorra a investigadores de um fundo vendedor a descoberto (short seller) e a contabilistas forenses.
- Sem encenações sem sentido. Não se trata de dizer ao modelo «escreve ao estilo de um fundo vendedor a descoberto», mas de lhe pedir que execute de facto um dos métodos de investigação desse tipo de fundo. Mudar apenas o tom não melhora o resultado.
O pré-requisito: o modelo precisa de um computador onde possa instalar software e de poder aceder aos dados relevantes, por exemplo através de conectores MCP.
V. As minhas notas de prática: da «transferência de dados» à «concretização da intenção»#
O que se segue é a minha extensão, a partir da 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 desenho não deve ficar numa pipeline passiva de transferência de dados como
generate_deck_pdf(), mas subir para a intenção de uma transição de estado como resolve_leadership_uncertainty_and_commit_budget().
- Defina uma função de perda verdadeira. Se só pedir um entregável, o modelo produz vacuidades aparentemente perfeitas; se pedir que resolva a incerteza da decisão, o modelo e o Sub-agent tapam por iniciativa própria as falhas lógicas e os limites de risco.
2. Divergir ao explorar, convergir ao validar#
- Ao explorar, primeiro diverge-se para encontrar possibilidades e depois converge-se.
- Ao validar, já não se diverge. Evite perguntas sem fronteiras como «de que outras formas se pode fazer isto?», que só trazem generalidades.
- Escreva explicitamente o âmbito do objetivo, as restrições e as ferramentas de verificação objetivas (um script de teste específico, um limiar de indicadores de negócio), para que a equipa Multi-Agent faça os testes de esforço num quadro focado e entregue um trabalho de alta qualidade.
Resumo das notas#
- 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 encontrar 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 apenas 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)