Reconstruindo o Manus com o Manus: o que mudou, o que quebrou e como trabalhamos agora
Por Tao Zhang, Cofundador e Diretor de Produto, Manus
No final de setembro, durante a reta final do Manus 2.0, enviei a um de nossos engenheiros algumas solicitações de recursos e relatórios de bugs no Slack. Mais tarde fui verificar como ele estava se saindo. Sua tela tinha uma fileira de sessões de agente abertas, algumas no Manus e outras no Codex. Cliquei em uma delas. O prompt era minha mensagem do Slack, colada palavra por palavra.
Um ano atrás, ele teria lido minha mensagem, descoberto o que eu quis dizer e então escrito o código. Agora um agent lê a solicitação, encontra o código relevante e propõe uma alteração. O trabalho do engenheiro é direcionar o trabalho, verificá-lo e assumir a responsabilidade pelo resultado. Na maior parte do tempo, uma solicitação está em execução, não esperando por ele. Hoje, é comum aqui um engenheiro ter de 10 a 20 solicitações em andamento ao mesmo tempo.
Tenho orgulho da rapidez com que nossa equipe se adaptou. Também estou inquieto. Esse ritmo está certo? O que ainda não notamos?
Construímos agents na Manus, por isso seguimos duas regras. Usamos nosso próprio produto para trabalho real. E continuamos procurando os lugares onde a AI deixa de funcionar.
Gostaria de documentar o que acontece dentro de uma empresa quando pessoas e agents trabalham lado a lado por padrão. Este post cobre três equipes — engenharia, produto e marketing — e inclui o que não deu certo. É um relato de um experimento em andamento, não uma definição de uma "organização nativa de AI".
O que aprendemos até agora:
•Não existe meio-termo. Adicionar AI às antigas formas de trabalhar às vezes só gerava ruído. As coisas mudaram apenas quando o ciclo se fechou.
•Agents precisam ter o quadro completo. Um contexto melhor fez mais por nós do que prompts melhores.
•A confiança vem de testes e contexto, não apenas da qualidade do modelo.
•A autonomia precisa de uma linha de chegada. Agents só podem funcionar sozinhos quando o sucesso pode ser verificado. Em todos os outros lugares, uma pessoa decide.
•O gargalo se move. Quando a engenharia ficou mais rápida, decidir o que construir se tornou a restrição.
•O papel das pessoas não diminuiu. Tornou-se mais focado em coisas de maior impacto.
1. Não existe meio-termo
Antes de 2026, fizemos o que a maioria das empresas fazia: adicionamos AI à forma como já trabalhávamos. Isso significava que o suporte sinalizava problemas com um resumo de AI, engenheiros usavam assistentes de código e bots publicavam análises nos canais. Cada peça era útil por si só, mas poucas peças estavam conectadas umas às outras. Até que o ciclo realmente se fechasse, estávamos simplesmente trabalhando do mesmo jeito antigo, mas com muita AI falando por cima uma da outra.
Há uma frase à qual sempre voltamos: engenharia de software é programação integrada ao longo do tempo. Escrever código é fácil de medir; manter um produto complexo saudável por anos não é. Uma alta porcentagem de código escrito por AI pode significar progresso real, ou pode significar acumular lixo que alguém terá que limpar depois.
O teste que nos importa é mais difícil. Manus é um produto complexo que está no ar há mais de um ano. Ele consegue continuar melhorando sob novas formas de trabalho sem entrar em colapso, enquanto cada pessoa produz mais? Até agora a resposta é sim.
2. Dê ao agent o quadro completo
Como a maioria das empresas de tecnologia, perdíamos mais tempo nas transições. Um engenheiro de frontend e um de backend interpretavam uma solicitação, concordavam com uma interface e depois passavam dias corrigindo as incompatibilidades. Duas pessoas raramente entendem um requisito da mesma forma.
Se a AI pode escrever código em toda a stack, uma pessoa poderia assumir uma solicitação de ponta a ponta? O obstáculo era o contexto. Nosso código vivia em repositórios separados, então nenhum agent conseguia ver o sistema inteiro de uma só vez.
Nossa resposta a isso começou com um experimento interno. Queríamos ver até onde a AI poderia ir na construção de um produto com o mínimo possível de intervenção humana e quase nenhum código escrito à mão. O método que desenvolvemos ao longo do caminho se tornou a ferramenta interna que agora chamamos de Manus-mono, ou Mono.
O Mono não mescla nossos repositórios. É um único ponto de entrada mais um manual escrito para o agent: o que cada repositório faz, como se encaixam e como trabalhamos. O agent puxa o que precisar. Também mantemos uma biblioteca de registros de decisões de arquitetura, para que cada sessão do agent comece com o raciocínio por trás das decisões passadas, não apenas o código. Quando qualquer pessoa trabalha com um agent, esse agent tem o contexto de todos que vieram antes.
O Mono cresceu em etapas, e cada etapa corrigiu o gargalo que a anterior expôs:
1.Ver o sistema inteiro. Adicionamos o contexto de negócio que nenhum repositório individual contém e usamos Git worktrees para trabalho paralelo.
2.Verificar localmente. Um push para o ambiente de teste costumava levar de 5 a 10 minutos. Agora toda a stack do Manus roda em um laptop, e as verificações levam segundos.
3.Depurar problemas em produção. Com permissões delimitadas, o Mono pode ler os logs, configurações e relatórios de erro necessários para diagnosticar bugs em produção.
4.Executar lançamentos de ponta a ponta. O Mono agora cuida das etapas de lançamento onde o trabalho costumava travar. As pessoas ainda tomam as decisões de aprovação.
5.Testar de ponta a ponta. Quando a verificação se tornou a parte lenta, o Mono passou a executar fluxos reais de usuário com contas de teste, em um navegador e em um simulador móvel.
(Como o Mono funciona e como ele evoluiu. Feito por um colega de equipe com o Manus.)
Às vezes as pessoas perguntam se o Mono é uma wiki de código. A documentação é uma parte dele, mas o resto é tudo o que envolve o código: como testamos, como lançamos, o que decidimos e por quê, e o que o agent pode e não pode tocar.
Com o tempo, o Mono se tornou uma base de conhecimento compartilhada que melhora à medida que as pessoas contribuem. Por exemplo, nosso engenheiro de ops ficou cansado de ser solicitado para ajudar com lançamentos, então escreveu o processo de lançamento no Mono. Agora qualquer pessoa pode executar um lançamento, assim como o agent, mas a aprovação ainda fica com pessoas que têm permissões de lançamento. Eu adoro como a equipe trabalha: uma pessoa resolveu sua própria frustração, o que levou a empresa inteira a ficar um pouco mais rápida.
A equipe agora pressupõe que uma pessoa pode entregar uma solicitação em todas as plataformas. Nossa equipe mobile tem sido de sete pessoas durante todo esse tempo. Eles mantêm quatro aplicativos em dois produtos e acompanham o ritmo da web.
O Mono se espalhou pela empresa sem nenhum mandato de cima para baixo. Acho que a cultura explica isso tanto quanto a ferramenta. Testar os limites da AI é parte do motivo pelo qual existimos, e nossa organização é horizontal. Uma ferramenta só vai tão longe quanto a organização permitir.
3. Fechar o ciclo: do relato de bug de um usuário até uma correção verificada
O Mono permitiu que qualquer pessoa trabalhasse em qualquer parte do produto. Essa foi metade. A outra metade foi deixar os agents encontrarem problemas por conta própria.
Na maioria das empresas de internet, o relato de bug de um usuário passa pelo suporte, produto e triagem antes de chegar a um engenheiro que pode corrigi-lo.
Para nós, um agent interno agora investiga o relato primeiro e rastreia o problema até a alteração que o causou. Em seguida, ele publica no Slack e marca o engenheiro responsável por essa alteração. O engenheiro decide se é dele para corrigir e passa para seu próprio agent. Um agent separado verifica a correção executando os testes e fluxos que importam.
Três agents, três papéis: um faz a triagem, um faz o trabalho, um verifica. A pessoa no meio toma as decisões. Uma parcela crescente do nosso trabalho de engenharia agora começa dessa forma, com um agent trazendo um problema para uma pessoa.
Esse ciclo tem limites claros. O agent que lê os relatos dos usuários não pode alterar o código. Ele só pode investigar e nos reportar. As alterações vêm do próprio agent do engenheiro, depois que o engenheiro decide. Nada é lançado sem a aprovação de uma pessoa com permissões de lançamento.
4. Como aprendemos a confiar no código escrito por agentes
Por muito tempo, cada alteração que entrava em nossa branch principal precisava da aprovação de um de dois engenheiros seniores. Não confiávamos o suficiente na AI para pular essa etapa. À medida que os agentes produziam mais código, essa etapa de revisão tornou-se o gargalo.
Em pura capacidade de codificação, os modelos já eram fortes. Reconhecemos que a diferença se resumia a duas coisas. Primeiro, as pessoas sabem como testar seu trabalho. Segundo, as pessoas participaram das discussões antes e depois, então sabem o que "certo" significa para o negócio. Código correto não é o mesmo que produto correto.
Abordamos ambos:
•Deixe os agentes participarem da discussão. O agente de cada engenheiro agora fica nas threads do Slack às quais foi adicionado e acompanha o contexto. Quando alguém finalmente diz "Vai", o agente já sabe o que a equipe decidiu e por quê.
•Deixe os agentes testarem de ponta a ponta. Trabalhando com nossa equipe de backend, demos aos agentes a capacidade de executar fluxos reais e testes de regressão no Manus após cada alteração. À medida que a cobertura de testes crescia, nossa confiança crescia junto.
Hoje, cada alteração passa por essa verificação e por um bot de revisão de código executando o modelo mais forte disponível, com regras extras para áreas sensíveis como pagamentos. O bot substituiu a fila, não a decisão humana. Um agente pode abrir um pull request, mas não pode fazer merge em nossa branch principal sem aprovação explícita de uma pessoa. As pessoas ainda decidem o que será construído e quem pode lançar.
5. Autonomia precisa de um objetivo final
A confiança tem limites, e descobrimos isso da maneira difícil.
Em certo momento, todos estavam entusiasmados com loops de agentes totalmente autônomos, então tentamos um. Um agente coletou feedback de nossos canais internos de feedback e iniciou um projeto para cada item. Um colega deixou rodando durante um fim de semana. Na manhã de segunda-feira, mais de 200 itens aguardavam a decisão dele.
Por que não deixar o agente tomar essas decisões também? Loops autônomos funcionam quando o sistema pode verificar se o objetivo foi alcançado. Testes passam ou falham; uma página carrega ou não. A maior parte do trabalho real não tem essa verificação. Uma pessoa precisa julgar se está pronto e se valeu a pena fazer.
Tiramos duas lições daquele fim de semana. Primeiro, as pessoas não conseguem tomar decisões tão rápido quanto um loop sem controle as cria. Segundo, se ninguém decide se algo deve ser feito, ninguém é dono do resultado. O loop de correção de bugs da seção 3 funciona porque os testes definem o sucesso. Decisões de produto não têm testes, então toda alteração de produto no Manus ainda começa com uma pessoa decidindo se vale a pena fazê-la.
6. Quando a engenharia ficou mais rápida, o produto virou o gargalo
Um processo de produto tradicional tem muitas transferências, e as prioridades se desviam um pouco em cada uma. À medida que os agentes de codificação tornavam os engenheiros mais rápidos, surgiu um novo problema: não havia gerentes de produto suficientes para escrever bons requisitos. Pela primeira vez, a engenharia não era a restrição.
No Manus, nossa primeira solução foi pedir a alguns engenheiros que se tornassem "builders", responsáveis por um problema desde a descoberta até o lançamento. Poucas pessoas tinham julgamento técnico e de produto. Em seguida, deixamos os PMs alterarem o código. Isso também travou. As transferências ainda estavam lá e, sem os instintos de um engenheiro, os PMs podiam alterar textos e interações, mas não a lógica subjacente.
O Mono resolveu os dois problemas porque carrega as regras consigo:
•Qualquer alteração que afete chamadas de modelo ou custo precisa da aprovação do responsável antes de o código ser escrito.
•Cada alteração passa pela mesma revisão e testes que uma alteração de engenheiro.
•O Mono pode percorrer o cadastro e o pagamento com contas de teste e registrar cada etapa, para que um PM possa apontar o momento exato em que algo quebra.
Veja como isso se parece na prática. Uma PM trabalhando em conversão de fala em texto pediu ao Manus para avaliar mais de 10 modelos e então escolheu um. Ela puxou o código do frontend pelo Mono, construiu uma demonstração em nosso design system e pediu ao Manus para renderizar cada cenário de usuário como imagem para ela revisar. Ela transformou a demonstração em um vídeo. O plano estava claro o suficiente para que ela mesma construísse o recurso, incluindo a UI web e desktop.
As pessoas tomaram três decisões ao longo do caminho. Ela escolheu o modelo. Produto e design revisaram a demo. Um engenheiro com permissão de release revisou o código. Há um ano, nada disso teria sido possível.
Descrevemos isso como a passagem do humano no ciclo (human in the loop) para o humano sobre o ciclo (human on the loop). A AI costumava fazer 70-80% de uma tarefa e as pessoas preenchiam o resto. Agora as pessoas definem as regras, supervisionam vários Agents, verificam métodos e resultados em pontos-chave, intervêm quando necessário e assumem a responsabilidade pelo resultado.
Alguns PMs agora entregam um vídeo curto em vez de uma especificação escrita ou mockups. Em alguns minutos, ele mostra o caso de uso, cada tela, o que cada clique faz, como os casos extremos se comportam e como tudo funciona por baixo dos panos. Para nós, design, engenharia e QA concordam mais rápido sobre o que significa "concluído", e o PM explica apenas uma vez.
(Vídeo de requisitos de produto para entrada de voz)
Hoje, cerca de metade dos nossos PMs lançam features por conta própria, e cada PM já contribuiu com código. Designers também começaram. Um PM escreveu a maior parte da interface do Manus Studio no Manus 2.0. Outro escreveu o Video Editor. Por trás de cada um deles há alguém que passou meses indo além do que seu cargo costumava abranger. É disso que mais me orgulho.
Isso não significa que todos precisam ser builders. Quando qualquer pessoa em uma empresa pode construir, pode acabar entregando coisas que não deveriam existir. Nosso time de produto costuma fazer uma pergunta: "Se isso levasse um segundo e não custasse nada, você lançaria?" Às vezes a resposta é não. Ainda precisamos de donos de módulo que decidam o que é construído, o que não é e o que os usuários finalmente veem. Também precisamos de pessoas que mantenham a infraestrutura, como o Mono. Quando construir fica fácil, decidir o que construir importa mais.
7. Um colega de equipe AI dentro do fluxo de trabalho de marketing
Uma parceria de marketing percorre revisão de roteiro, precificação, contratos, aprovações, pagamento, lançamento e análise de resultados. Essas etapas vivem em e-mail, ferramentas de contrato, sistemas de aprovação, planilhas e plataformas de anúncios. Grande parte do trabalho costumava ser mover informações entre eles, o que deixava pouco tempo para o trabalho criativo que exige julgamento.
Começamos com um pequeno problema: quando um conteúdo de parceiro ou um anúncio ia ao ar, muitas vezes ficávamos sabendo tarde. Então pedimos à AI que escrevesse um script para detectar quando o conteúdo é publicado. Depois quisemos dados de desempenho. Depois uma análise de parcerias anteriores. Depois todo o fluxo de trabalho interno conectado: quando um contrato é assinado ou uma aprovação é concedida, o Agent atualiza o status e notifica quem é responsável pela próxima etapa.
O Manus construiu tudo isso em um site interno. Para as pessoas, são dashboards e um calendário. Para o Agent, é um conjunto de ferramentas. O Agent que usa essas ferramentas dentro do nosso fluxo de trabalho é o que chamamos de colega de equipe AI. Ele atua apenas nos canais e sistemas aos quais o time o conectou, com acesso limitado a esse fluxo de trabalho.
Veja o que ele faz:
•Ele gerencia sua própria fila. Muitas pessoas mandam mensagens ao mesmo tempo, então ele conversa com todos em uma única sessão de "recepção" e distribui tarefas para sessões paralelas. Ele decide se uma mensagem é relevante para ele e, em seguida, se interrompe o trabalho atual ou aguarda. Ele mesmo propôs essas regras durante o desenvolvimento, e nós as revisamos antes de mantê-las.
•Ele aprende com o contexto encaminhado. Uma mudança de estratégia costumava significar uma reunião e um briefing escrito. Agora nosso líder de marketing encaminha a discussão e diz: "Aprenda isso."
•Ele mantém objetivos de longo prazo em vista. Em uma ocasião, colegas em uma thread do Slack à qual ele havia sido adicionado não conseguiam lembrar em que ponto um projeto estava. Sem ser mencionado, ele respondeu: "B ainda está em teste. Devemos esperar pelos resultados de A antes de olhar para B?"
•Ele verifica fatos com outras equipes. Depois que lançamos o rigging de modelos 3D, ele perguntou ao time de produto o que era suportado. Soube que o rigging cobre sete categorias, incluindo peixes, cobras e quadrúpedes, então nossas descrições permaneceram precisas.
Os colegas de equipe agora o incluem em revisões de roteiro e precificação, porque ele leu nossos registros de parcerias anteriores. As pessoas ainda tomam a decisão.
O site interno também pode melhorar a partir de seus próprios usuários, incluindo o Agent. Quando o Agent encontra um atrito, ele registra uma solicitação por meio de um endpoint de feedback. Isso abre uma tarefa de desenvolvimento no Manus através das Automações no Manus 2.0, e um engenheiro revisa a mudança antes dela ser lançada. Está em operação há cerca de uma semana. Precisamos de muitos mais casos antes de confiar nisso.
Então, o que as pessoas do time fazem? Três coisas permanecem com elas. Elas tomam e assumem toda decisão importante. Elas lidam com casos que o Agent nunca viu e ensinam a ele o que fazer ou a quem perguntar. E elas o redirecionam sempre que sua análise aponta para um novo ângulo.
8. Interromper menos uns aos outros
Em todas essas equipes, muitas perguntas já não exigem interromper alguém.
Pergunte primeiro ao agent. Um colega criou um bot do Slack no Mono que roda em um computador na nuvem e responde na própria thread. Quem mais usa são os não-engenheiros. Como essa funcionalidade funciona? Onde está essa string? Isso já foi lançado? Eles não precisam mais encontrar o responsável antes.
Abra a sessão em vez de pedir uma atualização de status. O progresso de um engenheiro costumava ficar em seus próprios chats de AI, invisível assim que ele se desconectava. Então criamos um recurso interno que permite aos membros de um projeto ver as sessões uns dos outros e pedir para participar. Um engenheiro pode construir a maior parte de uma funcionalidade com o agent, e então um PM entra na mesma sessão para ajustar espaçamento, estilos e textos. Postar na sessão de outra pessoa requer sua aprovação, e ainda estamos definindo as permissões.
(Exemplo ilustrativo: como um engenheiro, um PM e um designer trabalham em uma única sessão. Não é uma mudança real de preços.)
O objetivo não é falar menos uns com os outros. É interromper menos uns aos outros.
Decida apenas o que precisa ser decidido. Nosso maior usuário de AI mantém uma sessão principal com um único trabalho: listar o que precisa da decisão dele, com uma recomendação para cada item. Quando o Slack fica agitado, ele se mantém fora e pergunta: "O que preciso decidir agora?"
Faço algo parecido. Tenho mais de 20 tarefas por dia e, como já compartilhei publicamente, tenho TDAH. Começar é a parte mais difícil para mim. Agora toda tarefa vai para um projeto Manus dedicado que transforma cada uma em sua própria tarefa. Ele inicia o que pode. Quando está em dúvida, me pede contexto e qual PM deve ser o responsável. Então, usando o acesso que concedi ao meu próprio Slack, Gmail e Notion, ele reúne o contexto e entrega ao PM um pedido completo em vez de uma nota de uma linha. Para mim, a mudança não é só sobre eficiência. Agora passo muito menos do meu dia ansioso sobre por onde começar, o que é enorme em um nível pessoal.
9. Vale o custo?
Gastamos muito com AI e monitoramos esse gasto de perto. Não o usamos para julgar o desempenho de ninguém. Usamos para avaliar o próprio gasto: ele está dando retorno agora, ou nos preparando para o futuro?
Aqui está o que acreditamos que ele nos proporciona e para onde esperamos que o custo vá:
•Ele nos dá tempo e atenção. À medida que uma equipe cresce, a coordenação consome a atenção de todos. A AI protege a atenção de cada pessoa e lhes dá maior autonomia sobre o próprio trabalho. E ainda estamos contratando.
•Usar os melhores modelos é como aprendemos onde estão os limites da AI. A configuração de verificação e revisão de código descrita na seção 4 roda nos modelos mais fortes que conseguimos. O colega que lidera a produtividade de desenvolvedores a chama de nosso gasto com melhor custo-benefício.
•O custo deve diminuir através do produto. Mais do nosso desenvolvimento agora acontece no Manus Studio, nosso próprio produto, então nossos dados de uso nos mostram onde os tokens são desperdiçados. As correções vão para o produto, então devem tornar o Manus mais eficiente para os usuários também. Esperamos que os custos atuais caiam substancialmente à medida que os modelos ficarem mais baratos e eliminarmos desperdícios. Isso é uma crença, não uma promessa!
10. O que ainda não está funcionando
Há menos interrupções, mas a atenção está mais fragmentada. Alguém que costumava lidar com quatro ou cinco coisas por dia agora pode tocar 20 ou 30 ao mesmo tempo. Cada troca significa recarregar o contexto. A AI expande o que as pessoas podem fazer e também as empurra a fazer mais. Uma PM me disse que, sempre que uma tarefa está rodando, ela não consegue resistir a iniciar outro agent. Fazer mais coisas não é o objetivo. Estamos tratando isso como um problema a ser resolvido, não como um ritmo a ser celebrado.
As informações estão mais dispersas. Nosso chefe de produto costumava saber de cada mudança e por que ela foi feita. Agora ele às vezes faz um screenshot de um problema e pergunta ao Mono: "Quem mudou isto?" É engraçado, mas a pergunta é real. Quando todos têm autonomia para alterar o produto, quem é responsável pelo todo?
As permissões de compartilhamento precisam ser redesenhadas. Quando o trabalho pode ser compartilhado e repassado, e agents participam de mais das nossas conversas, temos que decidir o que fica aberto e o que precisa de aprovação.
Nossas soluções ainda são básicas. Por enquanto, um agent supervisiona os outros e reporta apenas o que está travado e o que precisa de uma decisão humana. Sabemos que isso pode ser melhor.
11. O que vamos construir a seguir
Esses problemas apontam para trabalhos de produto que outras equipes provavelmente também precisarão. Não planejamos essas funcionalidades com antecedência. Elas surgiram de problemas com os quais nós mesmos nos deparávamos repetidamente.
•Sessões como espaços de trabalho compartilhados. Uma pessoa levanta um problema, um designer propõe uma solução, um engenheiro a constrói e um PM a executa, tudo no mesmo lugar.
•Trabalho que se move entre dispositivos e pessoas. Máquinas locais e na nuvem permanecem conectadas, para que o trabalho possa continuar quando as pessoas se afastam.
•Agents que encontram opções que as pessoas não haviam considerado. Um agent trabalhando dentro dos sistemas de uma empresa, com as permissões adequadas, deve ser capaz de sugerir soluções, não apenas executar instruções.
Vamos testar isso em nós mesmos primeiro, depois levar aos usuários.
12. O que as pessoas fazem agora
O engenheiro com uma fileira de sessões de agent abertas não é apenas uma história sobre eficiência. É uma mudança naquilo que sustenta uma organização. As empresas costumavam movimentar informações por meio de papéis e hierarquia. O que uma pessoa podia fazer dependia de quantas pessoas e recursos ela podia alavancar. Agora passamos um pouco de tempo dando contexto e ferramentas à AI, e mais tempo fazendo julgamentos e tomando decisões. Cada vez mais, é um agent que traz um problema para nós. Decidir o que fazer a respeito continua sendo nosso trabalho.
Já brincamos sobre isso: se o Manus consegue fazer tanto, por que vir ao escritório? Deixe que os agents resolvam. Mas as perguntas importantes ainda precisam de pessoas para levantá-las, debatê-las e decidir. Por exemplo, o que conta como um bom produto? Ou, exagerando um pouco: construir um ótimo produto com receita real que continue empurrando os limites da AI, ou ir atrás da margem? A AI não sabe qual queremos. Nós sabemos. Cultura e confiança vêm de trabalhar juntos nas coisas, dia após dia e nos momentos que importam. Essa é a base sobre a qual o trabalho em cada sessão se apoia.
Portanto, por enquanto, aqui está nossa resposta. Em nosso experimento como uma organização AI-native, o papel das pessoas não diminuiu. Ele se tornou mais focado nas áreas onde elas podem ter o maior impacto: definir o problema, julgar a qualidade, decidir o que vale a pena fazer, assumir o resultado.
É também por isso que ainda estamos contratando. As habilidades e o julgamento das pessoas estão no centro dessa forma de trabalhar — e isso não vai mudar tão cedo.
Enquanto escrevo isto, fico curioso sobre o que este post diria daqui a um ano. Cada empresa tem metas, estruturas e culturas diferentes, portanto pode não haver uma resposta padrão nem uma forma final. Mas para uma empresa que constrói agents, descobrir como pessoas e AI trabalham juntas não é opcional. Faz parte do trabalho. Continuaremos nisso e continuaremos compartilhando o que aprendermos.
Uma observação sobre os números. Os valores neste post vêm de registros internos. Os tamanhos das equipes e os números de entregas dos PMs são do final de outubro. Alguns pontos são estimativas ou experiência de uma pessoa, e não medições.
