muitos membros da nossa equipe de engenharia começaram a usar @AmpCode dentro e fora do cursor. é objetivamente melhor do que todos os outros disponíveis hoje. também o temos a funcionar dentro do pre-commit hook (com Playwright mcp, etc.) e a fazer assistências na revisão de pr. com oráculos e subagentes, pode ser um dos sistemas multi-agente mais impressionantes que já vi.
Quinn Slack
Quinn Slack25/07/2025
Muitos agentes de codificação têm uma funcionalidade de "modos" que (mais ou menos?) fazia sentido numa era RAG ou de agentes iniciais. Agora estão a adicionar subagentes como o Amp (subagente de pesquisa, subagentes gerais, o oráculo) e o Claude Code (que acabou de lançar uma funcionalidade realmente interessante de subagentes personalizados). Os modos são menus suspensos de UI pesados e não compostáveis. Os subagentes são invocados através de linguagem natural ("use o oráculo para ...", "use o subagente de problemas para ...", ou implicitamente), são perfeitamente compostáveis e encaixam-se bem no modelo conceptual de chamada de ferramentas agenticas. Acontece que modos e subagentes servem basicamente ao mesmo propósito. Os subagentes são uma solução estritamente melhor. Assim, os agentes de codificação da geração anterior que têm uma funcionalidade de "modos" existente agora enfrentam uma escolha difícil ao adicionar subagentes: manter ambos os modos e subagentes (o que é confuso e complexo), eliminar os modos (o que é doloroso para a sua base de utilizadores porque eles investiram muito esforço na criação de modos), ou tentar esticar o conceito de "modos" para incluir também subagentes (o que também será confuso). Não os invejo. Na equipa do Amp, vivemos com medo mortal de estarmos nesta posição indesejável quando subestimamos onde a codificação agentica estará no futuro e precisamos fazer mudanças dolorosas no produto. Cometemos todos esses erros em produtos que construímos antes do Amp (e cometemos e vamos cometer muitos erros no Amp). É por isso que temos um padrão incrivelmente alto para adicionar novos conceitos de UI, é por isso que priorizamos membros da equipa com forte intuição, e é por isso que construímos para onde os modelos e o desenvolvedor médio estarão em 6-12+ meses, não hoje. Neste caso, acredito que esta orientação nos levou à decisão certa (sem modos, apenas subagentes compostáveis). Temos a sorte de poder construir para desenvolvedores incrivelmente inteligentes e de mente aberta/pensamento avançado que partilham o seu feedback frequentemente e através de praticamente todos os canais, exceto pombos-correio. Conhecemos e entendemos tão bem muitos de vocês. Simplesmente não conseguimos ver nenhum de vocês ou nós realmente amando "modos". Mas quando @thorstenball construiu subagentes e depois o oráculo, e disse que para usá-los, basta dizer ("use o oráculo para ...") em vez de selecioná-los de algum menu suspenso, pareceu-nos certo a nós e a todos vocês, e parecia que era para onde os modelos também estavam a ir. Parabéns a ele por isso, e obrigado aos nossos incríveis utilizadores por verem o futuro. Só queria partilhar um pouco dos bastidores sobre como pensamos sobre estas coisas e porque podemos parecer extremos ou rígidos em algumas questões. ...e fiquem atentos para este fim de semana, quando admitirei que estava errado sobre um dos nossos Feedbacks Frequentemente Ignorados (FIFs) mais controversos e farei uma mudança, graças a um monte de feedback que, afinal, não ignorei.
8,1K