Um LLM prevê tokens; um agente executa tarefas

Há uma frase que parece explicar toda a inteligência artificial aplicada ao código: um modelo de linguagem prevê o token seguinte.

A frase é tecnicamente útil. Também pode ser enganadora quando é utilizada para descrever o produto completo.

Um autocomplete recebe o contexto próximo do cursor e propõe uma continuação. Um agente de desenvolvimento pode receber um objetivo, explorar um repositório, consultar documentação, editar vários ficheiros, executar comandos, observar erros, tentar novamente e entregar um diff para revisão.

Nos dois casos existe um modelo a gerar tokens. O que muda é o sistema construído à sua volta.

Esta distinção importa porque Cursor, Codex, Claude Code e Google Antigravity não criam valor apenas por escreverem código mais depressa. A sua utilidade surge quando conseguem participar numa parte maior do ciclo de desenvolvimento: recuperar contexto, tomar decisões delimitadas, usar ferramentas, verificar resultados e devolver trabalho pronto para revisão.

Também explica os seus limites. Um modelo pode produzir código convincente e errado. Um agente pode transformar esse erro em alterações reais. À medida que aumenta a capacidade de execução, tornam-se mais importantes os testes, as permissões, o isolamento, a observabilidade e a revisão humana.

Em resumo

Um LLM gera tokens. Um autocomplete usa essa capacidade para propor uma continuação local. Um agente integra-a num sistema capaz de observar um ambiente, selecionar ferramentas, executar ações e corrigir-se a partir do resultado.

Isso não transforma o agente num programador infalível nem elimina a necessidade de uma pessoa responsável. Significa que a unidade de trabalho deixa de ser apenas a linha seguinte e pode passar a ser uma tarefa completa, como reproduzir um bug, acrescentar um teste, atualizar uma dependência ou preparar um pull request.

A utilidade real destas ferramentas depende de cinco condições:

1. O objetivo está suficientemente delimitado.
2. O agente recebe o contexto de que necessita.
3. Existem sinais verificáveis, como testes, compilação ou comportamento visível.
4. A alteração é reversível e passível de revisão.
5. O custo de controlar o resultado é inferior ao trabalho evitado.

A pergunta certa não é se a ferramenta “é autocomplete”. A pergunta é que parte do trabalho consegue concluir de forma verificável e dentro de que limites.

Um LLM pode prever tokens sem que o produto seja apenas autocomplete

Os modelos base de linguagem são treinados para prever a unidade seguinte de uma sequência. Essa unidade costuma ser expressa como token, não necessariamente como uma palavra completa. A partir do contexto anterior, o modelo atribui probabilidades às possíveis continuações e produz uma saída.

Este é o mecanismo generativo.

Mas um produto de desenvolvimento inclui outras camadas:

Camada	O que acrescenta
Modelo	Interpreta instruções, relaciona informação e gera código, planos ou chamadas a ferramentas.
Pós-treino	Ajusta o comportamento para seguir instruções, usar ferramentas e respeitar determinados limites.
Contexto	Fornece ficheiros, regras do repositório, histórico, documentação, erros e decisões anteriores.
Agente	Gere o ciclo de trabalho e decide de que informação ou ferramenta necessita a seguir.
Ferramentas	Permitem ler, pesquisar, editar, executar comandos, usar Git, consultar APIs ou interagir com outras aplicações.
Ambiente	Devolve sinais reais: testes, compilação, logs, navegador, diff, estado de uma tarefa ou resposta de um serviço.
Controlos	Limitam o filesystem, a rede, os segredos, os comandos, a identidade, o número de tentativas e as ações sensíveis.
Revisão humana	Verifica intenção, arquitetura, risco e alinhamento com necessidades que nem sempre estão documentadas.

Reduzir todo o sistema à previsão de tokens é como definir um navegador dizendo que executa instruções do processador. Não é falso, mas não permite distingui-lo de uma folha de cálculo, de um videojogo ou de um servidor.

Para avaliar um agente, é necessário observar o comportamento do conjunto.

Autocomplete, assistente e agente não são a mesma unidade de trabalho

A evolução destas ferramentas não é apenas uma escala de “mais código gerado”.

Autocomplete

Trabalha próximo do cursor. Sugere como continuar uma função, uma condição, um teste ou uma chamada a uma API.

A pessoa mantém o ciclo completo:

pensar → escrever → executar → interpretar → corrigir

O autocomplete reduz uma parte da escrita.

Assistente conversacional

Pode explicar uma arquitetura, propor uma função, rever um fragmento ou responder a perguntas sobre ficheiros fornecidos como contexto.

Aumenta a capacidade de análise, mas muitas vezes a pessoa continua a copiar informação para o chat e a transferir a resposta para o projeto.

Agente de desenvolvimento

Recebe um objetivo e pode operar dentro do ambiente:

objetivo
→ inspecionar o repositório
→ formular um plano
→ editar
→ executar ferramentas
→ observar o resultado
→ corrigir
→ verificar
→ entregar para revisão

A diferença não é apenas de comprimento. É uma diferença de controlo do fluxo.

Um agente pode escolher que ficheiro ler, que comando executar e quando a tarefa exige outra iteração. Segundo a definição utilizada pela OpenAI, o LLM controla a execução do workflow e seleciona ferramentas. A Anthropic distingue de forma semelhante os workflows com percursos predefinidos dos agentes que dirigem dinamicamente os seus processos e o uso de ferramentas.

O feedback do ambiente altera a qualidade do trabalho

Um modelo pode gerar uma função que parece correta. O terminal pode demonstrar que não compila.

Pode propor uma migração. Os testes podem revelar que quebra compatibilidade.

Pode afirmar que corrigiu um problema visual. Um navegador controlado pelo agente pode mostrar que o componente continua a transbordar no ecrã móvel.

O modelo não se torna determinístico por isso, mas reduz-se a dependência de uma única resposta plausível. O sistema pode confrontar a geração com evidência externa.

É por isso que o desenvolvimento de software é um terreno particularmente adequado aos agentes:

• existe código estruturado;
• muitas ações podem ser executadas num ambiente isolado;
• as alterações ficam representadas como diff;
• os testes fornecem critérios de aceitação;
• o Git permite comparar, reverter e rever;
• compiladores, linters e analisadores produzem sinais concretos.

A verificação automática também não é suficiente. Um teste pode estar incompleto, uma especificação pode ser ambígua e uma solução pode passar a suite enquanto piora a arquitetura. O ambiente fornece ground truth parcial, não critério total.

A revisão humana não nega a existência de um agente

Um sistema não precisa de publicar código sem autorização para ser um agente.

Imaginemos que recebe esta tarefa:

Descobre porque é que o checkout repete uma cobrança após um timeout, acrescenta um teste de regressão e prepara uma alteração para revisão.

Durante a execução pode:

• localizar a lógica de novas tentativas;
• reconstruir o percurso entre vários módulos;
• ler testes existentes;
• reproduzir a falha;
• modificar dois ou três ficheiros;
• executar a suite;
• corrigir um erro secundário;
• resumir a causa;
• apresentar o diff.

Se uma pessoa rever esse resultado antes do merge, o trabalho anterior não se transforma retroativamente em autocomplete.

A revisão define quem tem autoridade para aceitar a alteração. Também protege requisitos que o agente pode desconhecer: decisões de produto, convenções tácitas, dependências organizacionais, impacto operacional ou prioridades futuras.

Convém separar capacidade de autorização:

Nível	Capacidade do sistema	Autorização razoável
Assistência	Explica ou propõe código.	Pode responder diretamente.
Investigação	Lê e diagnostica.	Acesso só de leitura.
Preparação	Edita num branch ou worktree.	Escrita delimitada e testes.
Delegação	Conclui uma tarefa e prepara um PR.	Revisão antes de integrar.
Automação	Executa-se perante eventos ou cron.	Políticas por tipo de tarefa e limites de volume.
Operação sensível	Faz deploy, altera dados ou usa segredos.	Aprovação explícita, identidade separada e auditoria.

A autonomia útil não é “tudo ou nada”. Configura-se por ação, ambiente e risco.

O que acrescenta o Cursor

O Cursor combina várias superfícies no mesmo produto.

O Tab continua a ser autocomplete: propõe continuações enquanto a pessoa edita. O Agent pode pesquisar no codebase, ler e modificar ficheiros, utilizar o terminal e aceder a ferramentas MCP. O Cursor CLI leva o agente para o terminal e para scripts. Os agentes cloud podem trabalhar em máquinas isoladas, testar alterações e produzir artefactos como capturas, vídeos ou logs para acompanhar um pull request.

Esta combinação tem uma vantagem prática: permite alterar o nível de delegação sem abandonar o fluxo de trabalho.

Uma pessoa pode:

1. escrever manualmente uma parte sensível;
2. aceitar uma continuação local;
3. pedir uma edição em vários ficheiros;
4. delegar um bug a um agente cloud;
5. rever o resultado no IDE ou no GitHub.

O Cursor é particularmente útil quando o editor continua a ser o centro do trabalho e se pretende introduzir agência de forma progressiva.

O risco também nasce dessa fluidez. É fácil passar de uma pequena sugestão para uma edição ampla sem redefinir o âmbito. Por isso, convém rever o plano, o diff e os comandos, além de distinguir tarefas exploratórias de alterações que podem ser integradas.

O que acrescenta o Codex

O Codex CLI trabalha diretamente no terminal. Pode inspecionar código, modificar ficheiros, executar comandos, rever alterações e automatizar trabalho repetível. A configuração permite definir instruções do projeto, permissões e modos de revisão.

O Codex cloud altera a dimensão temporal. Cada tarefa pode receber um ambiente isolado e reproduzível, continuar enquanto a pessoa trabalha noutra coisa e regressar como um resultado pronto para revisão. Também permite iniciar trabalho a partir do GitHub, Linear ou Slack e executar várias tarefas em paralelo.

O seu valor surge em dois padrões.

Delegação fechada

A tarefa tem uma condição de saída reconhecível:

Atualiza esta API, mantém a compatibilidade, acrescenta testes e devolve um diff.

A pessoa investe tempo a especificar e rever, não necessariamente a executar cada passo.

Paralelismo

Enquanto um programador trabalha numa decisão arquitetural, vários agentes podem investigar bugs independentes, preparar documentação ou testar alternativas.

Esse paralelismo não elimina o custo. Transfere o bottleneck para a especificação, avaliação e integração. Se dez agentes produzirem dez alterações medíocres, a organização não multiplicou a produtividade: multiplicou a fila de revisão.

O que acrescenta o Claude Code

O Claude Code foi inicialmente orientado para o terminal, mas atualmente também funciona no IDE, desktop e navegador. Pode ler o codebase, editar ficheiros, executar comandos, trabalhar com Git, criar pull requests e ligar ferramentas externas através de MCP.

A extensibilidade é uma parte importante do produto.

Um ficheiro CLAUDE.md pode fornecer regras persistentes do projeto. As skills encapsulam procedimentos reutilizáveis. Os servidores MCP ligam sistemas como gestores de issues, observabilidade ou documentação. Os hooks executam controlos em pontos específicos do ciclo.

Os hooks mostram particularmente bem a diferença entre modelo e sistema.

Não é necessário confiar que o LLM se lembrará de executar o formatador após cada edição. Um hook determinístico pode fazê-lo sempre. Também não é necessário esperar que decida sozinho bloquear um comando perigoso: uma regra pode validá-lo antes da execução.

O Claude Code encaixa particularmente bem em equipas que querem construir um ambiente agêntico à volta do terminal, Git, scripts e ferramentas internas.

O que acrescenta o Google Antigravity

O Google Antigravity separa explicitamente a edição direta da coordenação de agentes.

O IDE inclui completamento, comandos e um agente capaz de operar no editor, terminal e navegador. O Antigravity 2.0 acrescenta uma superfície de gestão para lançar, observar e coordenar vários agentes em projetos e workspaces diferentes. Os subagentes podem dividir partes de um problema, as tarefas programadas permitem automatizar trabalho recorrente e os artefactos mostram planos, resultados e evidência de verificação.

A abstração central deixa de ser “uma conversa com o código” e passa a ser uma carteira de tarefas.

Isto é útil quando o trabalho pode ser dividido:

• um agente investiga a causa;
• outro prepara testes;
• outro valida a interface;
• outro revê uma migração;
• a pessoa compara artefactos e decide o que integrar.

O desafio é organizacional. Quanto mais agentes trabalham em paralelo, mais importante se torna evitar sobreposições, conflitos, objetivos ambíguos e revisões superficiais.

Não existe uma ferramenta universalmente melhor

As quatro ferramentas sobrepõem-se e as suas capacidades mudam rapidamente. A decisão deve partir do fluxo, não de um ranking.

Necessidade principal	Ferramenta a avaliar	Motivo
Permanecer no IDE e alternar entre Tab, edição e agente	Cursor	Integra diferentes níveis de assistência na mesma superfície.
Trabalhar a partir do terminal e delegar tarefas em ambientes cloud	Codex	Combina execução local, automação e trabalho isolado em paralelo.
Personalizar regras, hooks, skills e ligações a sistemas internos	Claude Code	Oferece uma superfície extensível à volta do terminal e das ferramentas.
Coordenar vários agentes e projetos através de artefactos	Antigravity	Dá prioridade à orquestração, subagentes, tarefas programadas e gestão de resultados.
Automatizar tarefas repetitivas em CI ou perante eventos	Cursor, Codex ou Claude Code	Os três oferecem modos programáticos; a escolha depende de permissões e integrações.
Manter supervisão máxima em alterações sensíveis	Qualquer um, com o ambiente certo	O controlo depende mais de permissões, branches, testes e aprovações do que da marca.

A comparação deve ser refeita periodicamente. Neste mercado, uma tabela de funcionalidades envelhece depressa. As perguntas mais estáveis são:

• Onde vive o contexto?
• Que ferramentas pode utilizar?
• Como isola a execução?
• Que evidência devolve?
• Como é revisto o resultado?
• Que ações exigem aprovação?
• Quanto custa operar e controlar o fluxo?

De onde vem a utilidade real

O benefício não se limita a escrever menos.

Recuperar contexto

Uma parte considerável do trabalho técnico consiste em encontrar ficheiros, reconstruir decisões, seguir chamadas, ler logs e lembrar como se executa um projeto.

Um agente pode reduzir esse custo de orientação, sobretudo em repositórios desconhecidos ou tarefas que atravessam várias camadas.

Fechar ciclos de verificação

Gerar código é barato. Verificá-lo costuma ser o trabalho importante.

Quando o agente pode executar testes, ler o erro e corrigir, absorve uma parte de um ciclo que antes exigia atenção contínua.

Evitar mudanças de contexto

Um bug pequeno pode demorar pouco a resolver, mas interrompe uma tarefa mais valiosa. Delegá-lo para um ambiente separado pode criar mais valor do que acelerar os minutos de implementação.

Tratar o backlog de baixa prioridade

Documentação, testes em falta, migrações repetitivas, atualizações mecânicas e falhas intermitentes são frequentemente adiados porque não justificam uma interrupção.

Um agente pode reduzir o custo de iniciar esses trabalhos.

Explorar alternativas em paralelo

Numa decisão reversível, várias tentativas independentes podem revelar soluções, riscos ou diferenças de implementação antes de a equipa comprometer o seu tempo.

O paralelismo só cria valor se existir depois um critério eficiente para comparar.

A evidência sobre produtividade é mista

Não existe um número universal que indique quanto acelera um agente de desenvolvimento.

Um ensaio controlado da METR, realizado com ferramentas do início de 2025, concluiu que 16 programadores experientes a trabalhar em repositórios que conheciam demoraram mais 19% quando podiam utilizar IA. Ainda assim, os participantes acreditavam ter trabalhado mais depressa.

Esse resultado não deve ser generalizado sem cautela. A METR apresenta-o atualmente como histórico e assinala que já não representa necessariamente as ferramentas de 2026. O estudo concentrou-se em programadores experientes, repositórios maduros e tarefas reais com cerca de vinte minutos a quatro horas.

Em fevereiro de 2026, a METR publicou dados posteriores com sinais de aceleração, mas considerou que a estimativa não era fiável. Alguns programadores evitavam participar porque não queriam ser atribuídos ao grupo sem IA; além disso, o uso simultâneo de vários agentes dificultava a medição do tempo humano investido.

Um estudo de campo sobre o deployment de Claude Code e Copilot CLI na Microsoft durante os primeiros meses de 2026 concluiu que os adotantes integraram aproximadamente mais 24% de pull requests do que a estimativa contrafactual. Os próprios autores alertam que um PR integrado é um proxy de output, não uma medida direta de valor, qualidade ou impacto.

Existe também um custo de aprendizagem. Um ensaio da Anthropic com 52 programadores concluiu que o grupo assistido por IA obteve um resultado de compreensão 17% inferior ao aprender uma biblioteca nova. Terminou apenas alguns minutos antes, mas essa diferença de tempo não foi estatisticamente significativa. Quem utilizou a IA para pedir explicações e construir compreensão reteve mais conhecimento do que quem delegou a solução.

Estas investigações medem situações diferentes. Em conjunto, sugerem algo mais útil do que uma média:

A produtividade depende do tipo de tarefa, do conhecimento prévio, da ferramenta, da forma de utilização, da possibilidade de verificar e da métrica escolhida.

Onde costumam funcionar melhor

Uma tarefa tem bom encaixe quando reúne várias destas propriedades.

Objetivo concreto

“Melhora a arquitetura” deixa demasiadas decisões em aberto.

“Extrai esta validação para um módulo, mantém a API pública e acrescenta testes para estes casos” define melhor o âmbito.

Resultado verificável

Compilação, testes, lint, tipos, snapshots, benchmarks ou comportamento no navegador permitem observar o progresso.

Alteração reversível

Um branch, worktree, patch ou ambiente cloud isolado reduz o custo de uma tentativa falhada.

Contexto acessível

O repositório inclui instruções, comandos, convenções, exemplos e decisões técnicas. O agente não precisa de adivinhar tudo o que a equipa sabe.

Revisão delimitada

O diff é compreensível e o resultado inclui uma explicação, os comandos executados e os riscos pendentes.

Com estas condições, costumam ser bons candidatos:

• bugs delimitados com teste de regressão;
• refactors mecânicos;
• atualização de dependências;
• migrações repetitivas;
• geração ou expansão de testes;
• investigação de erros de CI;
• documentação ligada ao código;
• protótipos descartáveis;
• análise inicial de um repositório;
• preparação de um pull request para revisão.

Onde podem piorar o trabalho

A utilidade diminui quando:

• o requisito é ambíguo;
• as regras de negócio não estão documentadas;
• não existe forma de validar o resultado;
• a alteração atravessa demasiados sistemas;
• existem decisões de produto por resolver;
• o repositório contradiz as suas próprias convenções;
• o agente recebe permissões ou segredos desnecessários;
• rever o código custa mais do que escrevê-lo;
• a equipa aceita output que não consegue explicar;
• uma pessoa em formação delega precisamente o raciocínio que precisa de aprender.

Outro risco é medir atividade em vez de progresso.

Mais linhas, commits ou pull requests podem significar mais valor. Também podem significar mais volume para rever, mais duplicação e mais dívida técnica.

A unidade correta é trabalho concluído e validado

Para avaliar estas ferramentas, convém abandonar a pergunta “quanto código gerou?” e observar o fluxo completo.

Dimensão	Métrica útil
Velocidade	Tempo desde a tarefa até um diff pronto para revisão.
Atenção humana	Minutos ativos de especificação, acompanhamento e revisão.
Aceitação	Percentagem da alteração mantida sem reescrita substancial.
Retrabalho	Correções necessárias depois da primeira entrega ou do merge.
Qualidade	Regressões, incidentes, resultados de testes e defeitos encontrados na revisão.
Fluxo	Tempo desde a issue até ao merge e tempo bloqueado.
Cobertura	Trabalho útil que anteriormente ficava por fazer.
Custo	Licenças, tokens, infraestrutura, execuções e revisão.
Risco	Permissões excessivas, exposição de dados, ações externas e incidentes.
Aprendizagem	Capacidade da equipa para explicar, depurar e manter o resultado.

Uma fórmula conceptual seria:

valor líquido =
tempo humano evitado
+ trabalho útil adicional
+ melhoria de qualidade
+ valor do paralelismo
- tempo de especificação e revisão
- retrabalho
- custo de execução
- risco introduzido
- perda de compreensão

Nem todos os termos são fáceis de monetizar. Ainda assim, a fórmula obriga a olhar para além da velocidade aparente.

Como Nicolás Torres abordaria o problema

Não começaria por comprar uma ferramenta para toda a equipa nem por impor uma quota de utilização.

Começaria por escolher três tipos de tarefa reais, frequentes e comparáveis. Por exemplo:

1. pequenas correções com teste de regressão;
2. diagnóstico de erros de CI;
3. atualização de documentação ou dependências.

Depois estabeleceria uma linha de base:

• duração total;
• tempo humano ativo;
• número de tentativas;
• tempo de revisão;
• retrabalho;
• defeitos posteriores;
• custo de interrupção;
• percentagem de tarefas abandonadas.

O piloto utilizaria um ambiente delimitado:

• instruções do repositório;
• branch ou worktree separado;
• acesso limitado ao filesystem;
• segredos fora de alcance;
• rede controlada;
• comandos definidos;
• testes obrigatórios;
• aprovação antes da integração;
• registo suficiente das ações.

Após várias semanas, compararia os resultados por tipo de tarefa e perfil de utilizador. Não misturaria um bug mecânico com uma decisão arquitetural, nem uma pessoa experiente no repositório com alguém que acabou de chegar.

Também reservaria períodos de trabalho sem delegação para aprendizagem. Uma equipa que produz mais código mas perde a capacidade de o compreender e corrigir está a transferir risco para o futuro.

A autonomia aumentaria apenas onde o resultado demonstrasse valor:

ler
→ propor
→ editar em isolamento
→ executar com baixo risco
→ preparar um PR
→ automatizar tarefas repetíveis

Fazer deploy, modificar dados reais ou utilizar credenciais sensíveis seguiria outro processo.

O que deve ficar claro ao escolher uma ferramenta

Antes de comparar modelos ou planos, procuraria respostas concretas para estas perguntas:

1. Pode trabalhar em todo o repositório ou apenas sobre contexto selecionado?
2. Que ações executa localmente e quais executa na cloud?
3. Como são reproduzidas as dependências e as variáveis do ambiente?
4. Que permissões tem sobre ficheiros, terminal, rede e ferramentas externas?
5. Pode separar cada tarefa num branch, worktree ou máquina isolada?
6. Que artefactos devolve para revisão?
7. Como regista comandos, tool calls e decisões?
8. O que acontece quando um teste falha ou o limite de tentativas é excedido?
9. Como se impede que leia segredos?
10. Como se calcula o custo real, incluindo revisão e retrabalho?

A melhor ferramenta não é a que gera a demonstração mais impressionante. É a que melhora um fluxo concreto sem tornar o risco opaco.

Conclusão

Um modelo de linguagem prevê tokens. Essa descrição explica uma parte essencial do seu funcionamento.

Não explica, por si só, o que é um agente de desenvolvimento.

Um autocomplete utiliza a previsão para sugerir uma continuação. Um agente insere-a numa arquitetura com contexto, ferramentas, estado, execução, feedback, permissões e condições de saída.

Cursor, Codex, Claude Code e Antigravity são úteis quando essa arquitetura permite concluir uma parte verificável do trabalho:

compreender
→ agir
→ verificar
→ corrigir
→ entregar

Não são infalíveis. Não tornam útil qualquer tarefa. Não substituem automaticamente o critério, a arquitetura, o conhecimento de negócio nem a responsabilidade humana.

Mas também não são corretamente explicados como sistemas que apenas escrevem a linha seguinte.

A adoção deve ser guiada por uma pergunta mais exigente:

Que trabalho útil consegue este agente concluir, que evidência devolve, quanto esforço humano evita e de que limites necessita para que o resultado seja fiável?

Quando essa pergunta tem uma resposta mensurável, a discussão deixa de ser semântica. Passa a ser uma decisão de engenharia.

Perguntas frequentes

Um LLM é apenas um sistema de autocomplete?

Ao nível do mecanismo generativo, um LLM prevê o token seguinte a partir do contexto. Mas essa descrição não chega para explicar um produto completo: o pós-treino, o contexto, as ferramentas, a memória, o ambiente de execução e os controlos alteram aquilo que o sistema consegue fazer.

O que distingue um autocomplete de um agente de desenvolvimento?

O autocomplete propõe uma continuação local. Um agente recebe um objetivo, explora o repositório, seleciona ferramentas, edita ficheiros, executa comandos, observa resultados e pode iterar até entregar uma alteração verificável.

Cursor, Codex, Claude Code e Antigravity fazem o mesmo?

Partilham capacidades agênticas, mas dão prioridade a superfícies diferentes. O Cursor combina completamento, IDE, CLI e agentes cloud; o Codex combina terminal e delegação em ambientes isolados; o Claude Code destaca terminal, extensibilidade, hooks e MCP; o Antigravity centra-se na coordenação de agentes, projetos e artefactos.

O facto de uma pessoa rever o código significa que o sistema não é um agente?

Não. A revisão humana define autoridade e responsabilidade. Um agente pode investigar, editar, testar e preparar um pull request e, ainda assim, parar antes de integrar ou fazer deploy porque essa ação exige aprovação.

Estas ferramentas aumentam sempre a produtividade?

Não. A evidência apresenta resultados diferentes consoante a ferramenta, a tarefa, a experiência, o repositório e a métrica. Podem acelerar trabalho delimitado e verificável, mas também aumentar a revisão, o retrabalho ou a perda de compreensão.

Como deve uma empresa avaliá-las?

Com tarefas reais, uma linha de base e métricas de trabalho concluído: tempo humano ativo, tempo até um diff para revisão, aceitação, retrabalho, regressões, custo, risco e capacidade da equipa para manter o resultado.