Ferramentas Simples, Desenvolvimento Autónomo: Como o Muse se Constrói a Si Próprio

TL;DR O Muse substitui consolas de orquestração de agentes feitas por medida por quatro ferramentas que qualquer equipa de software já tem abertas: Slack, Linear, GitHub e Claude Code. Sem dashboard, sem SPA, sem código escrito por humanos. Cada PR passa por sete portões de CI e um painel de revisão de IA com três personas, sob uma política de merge de zero observações. 40,000 votos recolhidos, avaliação de modelos fundacionais 80% mais rápida.

O Muse, abreviatura de Meshy Universal System for Evaluation, é a nossa plataforma interna de avaliação de modelos. As equipas da Meshy usam-na diariamente para perceber se os novos checkpoints de modelo têm um desempenho melhor do que os antigos.

Um dia, um checkpoint de um modelo novo e muito badalado tinha acabado de ficar pronto. Precisava de um confronto em arena para determinar a próxima estratégia de treino. A equipa percebeu que precisava de uma nova funcionalidade do Muse para o suportar.

"@Linear cria uma issue do Muse sobre isto"

disse o gestor de produto no Slack.

Um minuto depois, a issue MES-12345 foi criada no Linear.

O responsável pelo Muse — eu — viu a issue. Precisava de ir para produção o mais depressa possível para desbloquear a tarefa de avaliação. Depois, a mensagem foi enviada ao Claude:

"Investiga e corrige a MES-12345"

O Claude analisou a issue e depois levantou duas decisões de design. As decisões foram tomadas, e eu larguei o terminal para trabalhar noutra coisa.

Hora e meia depois, uma nova versão do Muse foi implementada em produção. Pronto.

A engenharia de software autónoma não precisa de ser consolas sofisticadas de orquestração de agentes ou dashboards. E, neste artigo, vou explicar como tornámos isso possível.

Uma galeria, um visualizador e um botão de voto

A pergunta a que o Muse responde é enganosamente difícil: será que o novo checkpoint de modelo é mesmo melhor? Claro que há métricas quantitativas para acompanhar em cada treino, mas estão longe de representar com precisão o que é "bom" na geração 3D. Por isso o Muse faz a coisa simples mas eficaz: testes duplamente cegos. Coloca os resultados de dois modelos lado a lado, com a mesma imagem de entrada, esquerda e direita aleatorizadas, e deixa a equipa votar às cegas.

Uma avaliação é um lote destes pares. Alguém aponta o Muse a dois conjuntos de meshes geradas e a uma pasta de imagens de referência, e a aplicação trata do resto: emparelha os modelos, cega a atribuição e apresenta uma comparação de cada vez. Os votos vão-se acumulando sempre que alguém tem um minuto livre. Toda a interface foi construída para ser consumida em pequenas doses, e é quase totalmente navegável com atalhos de teclado. Quem tem de recorrer ao rato vota menos.

A interface de votação do Muse: duas meshes geradas, a mesma imagem de entrada, esquerda e direita aleatorizadas.

É esse o produto. Uma galeria, um visualizador e um botão de voto. Nada na função do Muse é complicado, e é exatamente por isso que serve como um caso de estudo tão limpo. O que é invulgar é apenas a forma como é construído.

Uma arquitetura que os agentes conseguem navegar

O projeto Muse começou no final de 2025, quando o "vibe coding" se tinha acabado de tornar um novo palavrão da moda. Além de servir os crescentes esforços de avaliação da Meshy nos ciclos de treino e lançamento, o Muse tinha também um objetivo ambicioso: construir software para a empresa inteira, com zero linhas de código escritas por humanos.

Hoje, os resultados são excelentes:

• Mais de 40,000 votos recolhidos desde a entrega inicial do Muse, com mais de 30 projetos de avaliação por mês
• Mais de 4 equipas a usar ativamente o Muse no seu trabalho diário
• Primeira codebase interna com contribuições ativas de pelo menos 1 membro de equipa não técnico
• Primeira codebase interna a alcançar desenvolvimento totalmente autónomo

No total, estimamos que o Muse acelerou a avaliação dos nossos modelos fundacionais em pelo menos 80% e poupou pelo menos 10 pessoas-dia de trabalho em cada lançamento de modelo. Sem o Muse, manter o ritmo atual de desenvolvimento e lançamento da coleção de modelos generativos da Meshy, como geometria, textura e topologia inteligente, teria sido quase impossível.

Desde o primeiro dia, o Muse foi concebido para ser o mais legível possível para agentes. Em 2025, já tínhamos percebido que, para implementar o mesmo caso de uso, os agentes tinham dificuldades nalguns aspetos, enquanto noutros conseguiam à primeira tentativa. Muitas dessas iterações resultaram, por fim, na stack tecnológica deliberadamente aborrecida que temos hoje. O backend é em Python: FastAPI, Postgres para os registos, S3 para as meshes e imagens. O frontend é renderizado no servidor: templates Jinja2, HTMX para atualizações parciais de página, Tailwind para o estilo, e um único componente real do lado do cliente, o visualizador 3D em WebGL que renderiza as meshes. Não há SPA nem um módulo de frontend separado. O acoplamento entre as duas stacks é o mais antigo da web: o backend renderiza HTML, o browser mostra-o. Quando uma página precisa de mudar, o HTMX pede um fragmento e o servidor renderiza também esse fragmento.

Aqui está a arquitetura da aplicação principal de avaliação do Muse:

A arquitetura em camadas da aplicação principal de avaliação do Muse. As dependências apontam apenas para baixo.

Duas propriedades desta estrutura são importantes para os agentes. Primeiro, o estado do frontend vive no servidor. O HTML que o utilizador vê é o HTML que o backend produziu, por isso um teste (ou um agente) pode fazer asserções diretamente sobre ele, sem precisar de acionar uma framework do lado do cliente para reconstruir o que o utilizador viu. Segundo, todas as dependências são impostas pela máquina e apontam apenas para baixo. Uma pasta de funcionalidade não pode importar a sua irmã; se duas funcionalidades precisarem uma da outra, a raiz de composição injeta uma capacidade na outra, pelo que a dependência fica visível em exatamente um ficheiro. Cada camada tem uma única função, e essas funções estão escritas onde um agente inevitavelmente as vai encontrar:

As dependências apontam sempre para baixo nesta lista, e o sentido é imposto por uma verificação de build, não por uma convenção.

Três propriedades adicionais tornam a codebase deliberadamente legível para agentes:

• Cada diretório tem a sua própria documentação (o que o serviço faz, as suas regras de camadas, os comandos exatos que condicionam um merge), para que um agente a chegar "a frio" se consiga orientar sem perguntar ou inventar por conta própria.
• Os módulos não triviais têm docstrings com ligações de volta aos documentos de design, para que o porquê sobreviva ao lado do o quê.
• Nenhum ficheiro pode exceder as 500 linhas, com um mecanismo de catraca para os poucos casos de exceção. Nesses casos, os ficheiros podem encolher, nunca voltar a crescer. As janelas de contexto são finitas; a arquitetura respeita isso.

O progresso não deve viver numa salinha fechada

Hoje, com os agentes LLM muito mais poderosos do que em 2025, queremos que o desenvolvimento do Muse seja totalmente autónomo. Ou seja, o humano limita-se a apontar o agente para a tarefa. O agente orienta-se pela codebase e pelo contexto da tarefa, avança pela implementação, pelo CI e pela revisão de código, e por fim conduz a pull request sozinho até ao merge. O humano só determina a prioridade das issues e toma as decisões-chave de design.

As primeiras ideias sobre desenvolvimento totalmente autónomo costumam ser plataformas feitas por medida: consolas de orquestração, workspaces nativos para agentes, aplicação atrás de aplicação a prometer gerir a nossa "frota". Analisámos, e recusámos. Não porque não sejam bons produtos, mas por causa da legibilidade, mais uma vez.

Queremos que o trabalho dos agentes seja legível para os humanos, tal como a codebase deve ser legível para os agentes. Somos uma empresa de dimensão considerável. Se colocarmos o desenvolvimento autónomo dentro de uma consola personalizada, o seu progresso só fica visível para as poucas pessoas que vivem nessa consola.

Por isso, mais uma vez, a stack de ferramentas de colaboração e desenvolvimento é deliberadamente aborrecida. Tudo o que acontece na nossa história corre em quatro ferramentas que qualquer empresa de software já tem abertas: Slack, Linear, GitHub e Claude Code. Isto torna o progresso que o agente faz exatamente tão observável e pesquisável como o de qualquer membro da equipa. Um gestor de produto abre issues no Linear e verifica o estado das funcionalidades da forma como sempre fez. O bug bot do GitHub ou a revisão de segurança lê as threads da PR da forma como sempre leu. Quem reporta um bug cola uma captura de ecrã no mesmo canal de Slack de sempre, e a correção aparece como uma pull request normal. Ninguém precisa de aprender fosse o que fosse para supervisionar a "máquina".

Aqui está a forma de uma única issue autónoma, de ponta a ponta:

Uma issue autónoma, de ponta a ponta. O humano toca no ciclo em exatamente dois pontos.

O humano toca neste ciclo em exatamente dois pontos: ao apontar o agente para a issue do Linear, e nas poucas decisões que o agente levanta antes de escrever código. Tudo o que está no meio — a implementação, as verificações, a conversa de revisão, o merge e o deploy — corre sem ninguém ao volante. Quando uma verificação falha ou um revisor levanta uma objeção, o agente lê a falha, corrige-a e volta a fazer push, e o ciclo simplesmente dá mais uma volta. Só termina quando o branch está verde, todas as observações estão resolvidas e a queue já fez o merge.

O que torna isto possível não é uma integração feita por medida. É o facto de as três ferramentas já exporem superfícies de comandos que um agente consegue operar diretamente, as mesmas que uma pessoa usa:

• GitHub, através da sua CLI. O agente abre a pull request, lê o estado e os logs de cada job de CI, responde nas threads de revisão e marca-as como resolvidas, e coloca o branch na fila para merge, tudo através de comandos gh normais.
• Linear, através do seu servidor MCP. O agente lê a issue para a qual foi apontado, segue as ligações para issues relacionadas para obter contexto, muda o estado e cria issues de seguimento para trabalho que descobre pelo caminho, tudo como chamadas de ferramenta de primeira classe.
• O próprio ciclo de monitorização do Claude Code. O CI demora minutos e a fila de merge demora ainda mais, e não há nenhum humano a vigiar. É o agente que vigia, e a forma como o faz é o que transforma uma execução sem supervisão em algo prático, em vez de uma fogueira de tokens.

Quando o agente abre uma pull request, não fica sentado a atualizar uma página; regista aquilo que está a aguardar — a execução do CI, as threads de revisão, a entrada na fila de merge — e depois termina o turno. A funcionalidade Monitor do Claude Code só o volta a invocar quando esse estado observado muda: um job fica vermelho, o painel de revisão publica uma observação, a fila faz o merge do branch. Como o agente é acordado por mensagens do Monitor sobre cada atualização de estado, toma a ação seguinte em conformidade, como ir buscar o log de um job falhado e fazer push de uma correção, responder a uma thread de revisão e marcá-la como resolvida, ou colocar o branch na fila assim que todos os portões estiverem verdes.

Nada disto é específico do Muse. Qualquer repositório acessível a estas três ferramentas pode ser conduzido da mesma forma, e é exatamente por isso que as escolhemos.

A confiança é um artefacto de build

Não confiamos no LLM em si. Confiamos no agente LLM dentro de um harness, e o harness pode ser concebido para ser o guardião da fiabilidade. Em concreto, o harness é a nossa pipeline de CI/CD mais a camada de revisão por cima dela. É isto que toda a pull request atravessa, sem exceções:

Toda a pull request passa pelo mesmo harness: primeiro as verificações automatizadas, depois o painel de revisão por IA.

Os jobs individuais, com tempos típicos medidos em execuções reais e recentes de PRs:

Os guardrails são a arquitetura que descrevemos transformada em máquina. Aqui, uma importação entre pastas irmãs não é um comentário de revisão; é um build vermelho. Os goldens visuais são capturados no próprio ambiente de renderização do CI, para que "funciona na minha máquina" nunca possa ser argumento para fazer merge de um bug para a main.

A camada de revisão por IA é onde a coisa fica interessante. Cada PR é lida pelo nosso próprio painel de três agentes revisores de código, que leem o mesmo diff em confronto com os princípios de design escritos do repositório, cada um com uma persona diferente atribuída. Mostramos aqui um esboço dos prompts dados a cada revisor.

O Principal Engineer:

Persona: Principal Engineer, revisão de design, âmbito alargado

Revês ao nível do sistema: se esta alteração pertence ali, se encaixa na arquitetura, se reutiliza o que já existe e se se mantém aditiva — não se uma linha está arrumada.

Vês o diff + os Guides, não o repositório inteiro. Avalia a reutilização e a consistência de padrões ...; não reivindiques uma pesquisa em todo o repositório que não consegues fazer.

A tua lente: Avalia o diff face a estas partes dos Guides fornecidos ...

Teste decisivo: "Se eu fosse o principal engineer desta codebase, devolveria isto por estar no sítio errado, por duplicar uma capacidade já existente, ou por acrescentar uma segunda forma de fazer algo já resolvido?" Se não, devolve [].

O Senior Engineer:

Persona: Senior Engineer, lógica / implementação / qualidade

Revês dentro da alteração: se a lógica é correta, limpa, testável e segura. Esta é a revisão mais cuidadosa — segue os caminhos do código, não faças uma leitura por alto. Foca-te no diff e nos ficheiros que ele toca (lê-os na íntegra).

A tua lente: Avalia o diff face a estas partes dos Guides fornecidos ...

Teste decisivo: "Aprovaria esta lógica, ou encontraria um bug, um ponto intestável, ou um erro de segurança numa leitura cuidadosa?" Sê específico sobre o input ou o caminho de código que falha. Se a lógica for sólida, devolve [].

O QA Engineer:

Persona: QA Engineer, funciona, está testado, vai partir alguma coisa

Revês comportamento e risco: se esta alteração faz o que diz que faz, se está coberta por testes, e se pode partir algo em produção ou ao vivo. Lê o título e a descrição da PR, e depois verifica se o diff cumpre o que promete.

A tua lente: Correspondência de intenção ...; Cobertura de testes ...; Risco de regressão ...; Armadilhas de produção ...

Teste decisivo: "Se eu fosse o QA a dar o aval final, bloquearia isto por não fazer o que diz, por lançar comportamento não testado, ou por uma alteração que parte a produção?" Se for seguro e estiver coberto, devolve [].

Além de olharem para o mesmo diff de código a partir de ângulos diferentes, os 3 revisores partilham também um conjunto comum de regras que regem o desenvolvimento de toda a codebase, ou seja, os Guides:

• As coisas que mudam juntas vivem juntas; as coisas sem relação mantêm-se separáveis. Alterar ou eliminar uma preocupação toca apenas num sítio.
• A lógica de negócio não depende dos detalhes do mundo exterior. Uma função de lógica de negócio corre num teste com fakes passados como argumento, sem I/O real. Trocar um backend não toca em nenhuma lógica de negócio. A aplicação nunca chama os seus próprios endpoints HTTP.
• Reutiliza, não reinventes. Cada capacidade tem uma implementação; um novo consumidor chama a interface existente em vez de a copiar.
• Adiciona funcionalidades acrescentando, não editando. Adicionar uma funcionalidade é "novos ficheiros + uma linha de registo", e eliminá-la não toca em nenhuma outra funcionalidade.
• Uma única forma estabelecida de fazer cada coisa. Um recém-chegado copia o padrão existente em vez de escolher, e os testes não precisam de servidor nem de base de dados.
• Elimina código no momento em que deixa de ser usado. Não se lança nada que ninguém chama; "manter por precaução" não é motivo, porque o git lembra-se.
• Prefere a coisa mais simples que funciona; só acrescenta complexidade quando forçado. Cada abstração conquista o seu lugar com uma necessidade concreta e atual. A alteração é a mais pequena que resolve o problema.

O painel publica cada observação bloqueante como um comentário inline ancorado à linha exata, e esses comentários condicionam o merge até serem resolvidos.

Uma revisão de uma PR de funcionalidade recente tem este aspeto:

[médio] Risco de regressão. Esta função é o ponto de estrangulamento partilhado de criação e sincronização; agora agrupa ficheiros com sufixo de view numa única linha agrupada. Qualquer dataset pré-existente, ingerido segundo o esquema antigo, será, na próxima sincronização, reagrupado silenciosamente, eliminando as identidades de amostra antigas que avaliações em curso ainda referenciam. Nenhum teste cobre a re-sincronização de um dataset existente através do novo agrupamento.

Essa observação estava correta. O código tinha passado toda a suite de testes e uma primeira ronda de CI verde. Os testes estavam certos para o código tal como estava escrito. O revisor percebeu que o código, tal como escrito, estava errado para os dados que realmente temos. O Claude corrigiu-o, acrescentou o teste de regressão em falta, respondeu na thread e resolveu a observação. Toda a troca fica pública na PR, exatamente da mesma forma como se orientaria um engenheiro júnior numa revisão de código.

Essa foi uma PR. À medida que corremos o agente ao longo do tempo, conseguimos ainda descobrir outros padrões típicos:

• Uma correção que cria um novo problema. Uma ferramenta de diagnóstico que lançámos media a velocidade de download. A revisão detetou que o cálculo usava MB (1,000,000 bytes), mas o servidor enviava MiB (1,048,576 bytes), pelo que toda a velocidade seria lida 5% abaixo do real. Alguns pushes depois, a revisão assinalou que a correção deixava duas constantes sincronizadas manualmente. Por isso, pediu que a velocidade passasse a ser calculada a partir dos bytes efetivamente recebidos. O revisor apanhou um bug que fora criado ao resolver o seu próprio pedido anterior.
• Casos de uso sem saída. A mesma página foi lançada com a sua ligação visível para qualquer utilizador com sessão iniciada, mesmo que a própria página exigisse uma permissão específica. Quem não tivesse essa permissão clicaria e receberia um erro 403. Nenhum teste falhou, já que a ligação aparecia e o controlo de permissão funcionava. O revisor de QA comparou os dois aspetos e bloqueou o merge até a ligação só aparecer para quem realmente pudesse abrir a página.
• Fazer batota para passar nos testes. O teste de uma correção fabricava exatamente a exceção que devia apanhar, pelo que passava mesmo que o tratamento de erros real estivesse avariado, porque o teste recebia a mensagem de exceção "correta". O painel assinalou isto, e o teste reescrito faz passar erros reais pelo código real. A mesma PR tinha também um teste que passava na máquina do programador mas falhava no CI, porque dependia silenciosamente de um ficheiro de credenciais que só existe na nossa máquina de desenvolvimento. Ambos eram bugs nos próprios testes, apanhados pela camada acima deles.

A nossa política de merge é 0 observações da revisão por IA. Cada observação é corrigida, ou contestada com provas, antes de a fila aceitar a PR. Tornámos a contestação uma opção viável porque o painel de revisão assinala em excesso a uma taxa tolerável. Escrever porque é que uma observação está errada pode, por sua vez, apanhar ocasionalmente um erro no próprio raciocínio do painel de revisão.

Depois das verificações, a fila de merge revalida cada branch contra a ponta móvel da main, e um merge faz o deploy para produção automaticamente, sem nenhum humano no processo.

Depois de todos os portões, a fila de merge revalida o branch e um merge faz o deploy para produção.

As linhas de código são uma pequena parte da história

Ao longo de muitas PRs autónomas, encontrámos um padrão surpreendente mas razoável: o tempo gasto a iterar sobre verificações e revisões é muito mais longo do que o tempo gasto a escrever a primeira implementação, e a proporção também varia muito consoante o tipo de tarefa. Aqui comparamos dois tipos de tarefas de desenvolvimento na mesma semana.

Caso A: retirar uma funcionalidade morta. Uma pequena funcionalidade legada foi desativada; a sua ligação, o diálogo de confirmação, a tradução, os testes e a baseline de capturas de ecrã tiveram todos de desaparecer. Da criação da issue no Linear até ao merge da PR na main levou apenas 16 minutos, com os primeiros 2 minutos a escrever código. As revisões foram apenas consultivas.

Caso B: uma melhoria importante na funcionalidade de diagnóstico de rede. Foi uma alteração de dimensão semelhante em número de linhas, com a primeira versão concluída em 5 minutos, enquanto o tempo total até ao merge foi de cerca de 3 horas. Ao longo do processo, o agente resolveu 5 rondas de revisão e 7 observações bloqueantes de merge.

As cronologias também são bastante diferentes:

Duas tarefas com um número de linhas comparável, com esforço de verificação proporcional ao risco.

O segundo caso demora onze vezes mais, não porque o código fosse mais difícil de escrever, mas porque o risco era diferente, e o esforço de verificação foi gasto de forma proporcional. O Caso A era uma eliminação: o pior resultado possível era uma ligação avariada que já não devia ser visitada. O Caso B era uma ferramenta de medição: o pior resultado possível era todos os utilizadores confiarem num número errado. O painel de revisão encontrou os erros, e depois passou mais três rondas a recusar correções parciais até o tratamento de erros estar tipado, completo e exaustivamente testado. Cada ronda tornou a implementação estritamente mais rigorosa. Nenhum desses defeitos falhou um teste, e todos eles teriam ido para produção.

É esta a parte que a geração de código de um só golpe erra por construção. A geração de um só golpe otimiza a métrica mais fácil de ver: o tempo entre o prompt e um código que compila e corre. Os nossos dois casos atingiram essa métrica em minutos, e se tivéssemos parado ali, o Caso B teria ficado pronto poucos minutos depois de começar — e errado durante meses.

A mesma pipeline que deixou passar uma eliminação em 16 minutos reteve uma ferramenta de medição durante 3 horas, sem nenhum humano a decidir qual tratamento cada uma merecia. Quando perguntam se o código escrito por IA pode ser confiável em produção, é esta a resposta: o código é exatamente tão confiável quanto a verificação que o envolve, e a profundidade da verificação é hoje algo que se compra com horas de agente, em vez de dias de engenheiro. Um relatório de velocidade errado custa mais do que três horas assim que alguém encaminhar uma reclamação de rede com base nele.

O que aprendemos e o que vem a seguir

Hoje, a autonomia é mais uma propriedade do harness do que do modelo. Cada melhoria de modelo tornou os nossos agentes melhores; no entanto, a capacidade do modelo em si não vem com garantia de que se possa confiar no agente para fazer merge livremente das suas pull requests. Em vez de investir mais atenção humana ou usar cegamente o modelo de fronteira mais caro, optámos por construir as "mãos" e os "olhos" para que os agentes tenham tudo o que precisam para produzir código de produção correto. E, com a evolução da capacidade dos modelos, isto também nos permite acompanhar a onda, em vez de reconstruir o andaime para compensar as limitações dos modelos.

O papel do humano concentra-se, não desaparece. O que resta é o núcleo irredutível: decidir o que vale a pena construir, escrevê-lo com clareza suficiente, e exercer juízo nos momentos que as máquinas assinalam como ambíguos. O bom gosto de design e a qualidade das especificações são agora a competência de engenharia com maior alavancagem nesta equipa.

E a conclusão mais interessante sobre equipas de agentes é que o valor da equipa vem do conflito, e não da colaboração. Pode fazer sentido dividir uma tarefa full-stack entre agentes de frontend e de backend. Já faz menos sentido ter um agente de frontend e um agente de backend a falar um com o outro só para completar a tarefa. O benefício da equipa surge quando os membros têm objetivos em conflito. O nosso agente de desenvolvimento do Muse quer lançar o código. Os nossos agentes de revisão por IA querem encontrar onde o código está errado ou mal concebido. É a tensão entre eles que torna o resultado confiável, e que revela fielmente a quantidade real de trabalho de uma tarefa de desenvolvimento.

Mais importante ainda, percebemos que as nossas explorações nos conduzem a uma forma emergente de desenvolver software: uma organização de engenharia autónoma. Embora tenhamos demonstrado que os agentes conseguem completar tarefas individuais de forma autónoma com as ferramentas existentes, algumas peças em falta e questões em aberto convidam a futuros esforços:

• Até que ponto conseguimos escalar sistemas deste tipo? À medida que as organizações autónomas trabalham em tarefas e projetos cada vez maiores, com mais agentes em paralelo, que novos problemas vão surgir?
• Como podem os próprios resultados do harness, como as taxas de sucesso do CI à primeira tentativa e as observações da revisão por IA, tornar-se sinais de avaliação? Como medimos o desempenho de um agente na organização, e como o tornamos autoevolutivo?
• Como pode o gosto humano em design e produto ficar incorporado nestes sistemas? Se a engenharia pode ser tornada autónoma com juízos humanos esparsos, até onde podemos levar isto para resolver as questões de para quem devemos construir o software, e qual deve ser o seu aspeto?

Por fim, obrigado por teres lido até ao fim. A lista de tarefas para encontrar respostas a estas perguntas vive, muito apropriadamente, no Linear, onde o nosso próximo agente — ou tu — poderá pegar nela.