Reconstruir o Manus com o Manus: O que mudou, o que falhou 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 dos nossos engenheiros alguns pedidos de funcionalidades e relatórios de bugs no Slack. Mais tarde fui ver como ele estava a progredir. No ecrã dele havia uma fila de sessões de agentes abertas, algumas em Manus e outras em Codex. Cliquei numa delas. O prompt era a minha mensagem do Slack, colada palavra por palavra.
Há um ano, ele teria lido a minha mensagem, percebido o que eu queria dizer e depois escrito o código. Agora um agente lê o pedido, encontra o código relevante e propõe uma alteração. O trabalho do engenheiro é orientar o trabalho, verificá-lo e assumir a responsabilidade pelo resultado. Na maior parte do tempo um pedido está em execução, sem estar à espera dele. Hoje, é comum aqui um engenheiro ter 10 a 20 pedidos a decorrer em simultâneo.
Estou orgulhoso da rapidez com que a nossa equipa se adaptou. Também estou inquieto. Será este o ritmo certo? O que é que ainda não notámos?
Construímos agentes na Manus, por isso regemo-nos por duas regras. Usamos o nosso próprio produto para trabalho real. E continuamos a procurar os sítios onde a AI deixa de funcionar.
Gostaria de documentar o que acontece dentro de uma empresa quando as pessoas e os agentes trabalham lado a lado por defeito. Este artigo cobre três equipas — engenharia, produto e marketing — e inclui o que não funcionou. É um relato de uma experiência em curso, não uma definição de uma "organização AI-nativa".
O que aprendemos até agora:
•Não existe meio-termo. Adicionar AI às antigas formas de trabalhar por vezes acrescentou ruído. As coisas só mudaram quando o ciclo se fechou.
•Os agentes precisam do panorama completo. Melhor contexto fez mais por nós do que melhores prompts.
•A confiança vem dos testes e do contexto, não apenas da qualidade do modelo.
•A autonomia precisa de uma linha de chegada. Os agentes só podem funcionar por conta própria quando o sucesso pode ser verificado. Em todos os outros lados, é uma pessoa que decide.
•O estrangulamento desloca-se. Quando a engenharia ficou mais rápida, decidir o que construir tornou-se a limitaçã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: adicionámos AI à forma como já trabalhávamos. Isto significava que o suporte sinalizava problemas com um resumo de AI, os engenheiros usavam assistentes de código, e bots publicavam análises nos canais. Cada peça era útil por si só, mas poucas das peças estavam ligadas entre si. Até o ciclo se fechar efetivamente, estávamos simplesmente a trabalhar da mesma forma antiga mas com uma série de AIs a falar umas por cima das outras.
Há uma frase à qual regressamos muitas vezes: a engenharia de software é programação integrada ao longo do tempo. Escrever código é fácil de medir; manter um produto complexo saudável durante anos não é. Uma elevada percentagem de código escrito por AI pode significar progresso real, ou pode significar acumular lixo que alguém terá de limpar mais tarde.
O teste que nos importa é mais difícil. O Manus é um produto complexo que está em funcionamento há mais de um ano. Consegue continuar a melhorar com novas formas de trabalhar sem colapsar, enquanto cada pessoa faz mais? Até agora, a resposta é sim.
2. Dê ao agente o panorama completo
Como a maioria das empresas tecnológicas, perdíamos mais tempo nas transições. Um engenheiro de frontend e um engenheiro de backend interpretavam cada um um pedido, acordavam uma interface e depois passavam dias a corrigir as incompatibilidades. Duas pessoas raramente entendem um requisito da mesma forma.
Se a AI consegue escrever código em toda a stack, poderia uma pessoa ser responsável por um pedido de ponta a ponta? O obstáculo era o contexto. O nosso código vivia em repositórios separados, pelo que nenhum agente conseguia ver o sistema inteiro de uma só vez.
A nossa resposta a isso começou com uma experiência interna. Queríamos ver até onde a AI podia ir na construção de um produto com o mínimo de intervenção humana possível e quase nenhum código escrito à mão. O método que desenvolvemos ao longo do caminho tornou-se a ferramenta interna que hoje chamamos de Manus-mono, ou Mono.
O Mono não funde os nossos repositórios. É um ponto de entrada único mais um manual escrito para o Agent: o que cada repositório faz, como se encaixam e como trabalhamos. O Agent vai buscar o que precisa. Também mantemos uma biblioteca de registos de decisões de arquitetura, para que cada sessão do Agent comece com o raciocínio por detrás das decisões anteriores, e não apenas com o código. Quando alguém trabalha com um Agent, esse Agent tem o contexto de todos os que vieram antes.
O Mono cresceu em etapas, e cada etapa resolveu o estrangulamento que a anterior expôs:
1.Ver o sistema inteiro. Adicionámos o contexto de negócio que nenhum repositório individual contém e usámos worktrees do Git para trabalho paralelo.
2.Verificar localmente. Um push para o ambiente de teste costumava demorar 5 a 10 minutos. Agora toda a stack do Manus corre num portátil, e as verificações demoram segundos.
3.Depurar problemas em produção. Com permissões delimitadas, o Mono pode ler os logs, a configuração e os relatórios de erro de que precisa para diagnosticar bugs em produção.
4.Executar lançamentos de ponta a ponta. O Mono trata agora das etapas de lançamento onde o trabalho costumava emperrar. As pessoas continuam a tomar as decisões de aprovação.
5.Testar de ponta a ponta. Quando a verificação se tornou a parte lenta, o Mono começou a executar fluxos reais de utilizadores com contas de teste, num browser e num simulador móvel.
(Como o Mono funciona e como evoluiu. Feito por um colega de equipa com o Manus.)
Às vezes perguntam-nos se o Mono é uma wiki de código. A documentação é uma parte, mas o resto é tudo o que está à volta do código: como testamos, como lançamos, o que decidimos e porquê, e o que o Agent pode e não pode tocar.
Com o tempo, o Mono tornou-se uma base de conhecimento partilhada que melhora à medida que as pessoas contribuem para ela. Por exemplo, o nosso engenheiro de operações cansou-se de que lhe pedissem ajuda com lançamentos, por isso escreveu o processo de lançamento no Mono. Agora qualquer pessoa pode executar um lançamento, e o Agent também, mas a aprovação continua a caber às pessoas com direitos de lançamento. Adoro a forma como a equipa trabalha: uma pessoa resolveu a sua própria frustração, o que levou toda a empresa a ficar um pouco mais rápida.
A equipa parte agora do princípio de que uma pessoa pode lançar um pedido em todas as plataformas. A nossa equipa móvel manteve-se com sete pessoas durante todo este tempo. Mantêm quatro apps em dois produtos e acompanham o ritmo da web.
O Mono espalhou-se pela empresa sem qualquer mandato vindo de cima. Acho que a cultura explica isso tanto quanto a ferramenta. Testar os limites da AI é parte da razão da nossa existência, e a nossa organização é horizontal. Uma ferramenta só vai tão longe quanto a organização permitir.
3. Fechar o ciclo: do relatório de bug de um utilizador a uma correção verificada
O Mono permitia que qualquer pessoa trabalhasse em qualquer parte do produto. Essa era metade da história. A outra metade era deixar que os Agents encontrassem problemas por si próprios.
Na maioria das empresas de internet, o relatório de bug de um utilizador passa pelo suporte, produto e triagem antes de chegar a um engenheiro que o possa corrigir.
Para nós, um Agent interno investiga agora primeiro o relatório e rastreia o problema até à alteração que o causou. Depois publica no Slack e marca o engenheiro responsável por essa alteração. O engenheiro decide se é dele corrigir e entrega-o ao 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-o. A pessoa no meio toma as decisões. Uma parte crescente do nosso trabalho de engenharia começa agora desta forma, com um Agent a trazer um problema a uma pessoa.
Este ciclo tem limites claros. O Agent que lê os relatórios dos utilizadores não pode alterar código. Só pode investigar e reportar-nos. As alterações vêm do próprio Agent do engenheiro, depois de o engenheiro decidir. Nada é lançado sem a aprovação de uma pessoa com direitos de lançamento.
4. Como aprendemos a confiar em código escrito por agentes
Durante muito tempo, cada alteração que entrava no nosso ramo principal precisava da aprovação de um de dois engenheiros seniores. Não confiávamos o suficiente na AI para dispensar esse passo. À medida que os agentes produziam mais código, essa etapa de revisão tornou-se o estrangulamento.
Em termos de capacidade pura de programação, os modelos já eram fortes. Reconhecemos que a diferença se resumia a duas coisas. Primeiro, as pessoas sabem como testar o seu trabalho. Segundo, as pessoas participaram nas discussões a montante e a jusante, por isso sabem o que significa "correto" para o negócio. Código correto não é o mesmo que produto correto.
Abordámos ambos:
•Deixar os agentes participar na discussão. O agente de cada engenheiro agora está presente nas threads do Slack a que foi adicionado e acompanha o contexto. Quando alguém finalmente diz "Avança", o agente já sabe o que a equipa decidiu e porquê.
•Deixar os agentes testar de ponta a ponta. Trabalhando com a nossa equipa 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 dos testes crescia, a nossa confiança crescia com ela.
Hoje, cada alteração passa por essa verificação e por um bot de revisão de código que executa o modelo mais forte disponível, com regras extra 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 no nosso ramo principal sem aprovação explícita de uma pessoa. As pessoas continuam a decidir o que é construído e quem pode fazer o lançamento.
5. A autonomia precisa de um objetivo final
A confiança tem limites, e descobrimos isto da forma mais difícil.
A dada altura, todos estavam entusiasmados com ciclos totalmente autónomos de agentes, por isso experimentámos um. Um agente recolheu feedback dos nossos canais internos de feedback e iniciou um projeto para cada item. Um colega deixou-o a correr durante um fim de semana. Na segunda-feira de manhã, mais de 200 itens aguardavam a sua decisão.
Porque não deixar o agente tomar também essas decisões? Os ciclos autónomos funcionam quando o sistema pode verificar se o objetivo foi alcançado. Os 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 tem de julgar se está feito e se valeu a pena fazê-lo.
Tirámos duas lições desse fim de semana. Primeiro, as pessoas não conseguem tomar decisões tão depressa quanto um ciclo descontrolado as cria. Segundo, se ninguém decide se algo deve ser feito, ninguém é dono do resultado. O ciclo de correção de bugs da secção 3 funciona porque os testes definem o sucesso. As decisões de produto não têm testes, por isso cada alteração de produto no Manus ainda começa com uma pessoa a decidir se vale a pena fazê-la.
6. Quando a engenharia ficou mais rápida, o produto tornou-se o estrangulamento
Um processo de produto tradicional tem muitas transferências de responsabilidade, e as prioridades desviam-se um pouco em cada uma delas. À medida que os agentes de programação tornavam os engenheiros mais rápidos, surgiu um novo problema: não havia gestores de produto suficientes para redigir bons requisitos. Pela primeira vez, a engenharia não era a restrição.
No Manus, a nossa primeira solução foi pedir a alguns engenheiros que se tornassem "construtores" responsáveis por um problema desde a descoberta até ao lançamento. Poucas pessoas tinham simultaneamente o discernimento técnico e de produto. Depois deixámos os PMs alterarem código. Isso também estagnou. As transferências continuavam 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 ambos os problemas porque leva as regras consigo:
•Qualquer alteração que toque em chamadas de modelo ou custos 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 um engenheiro.
•O Mono pode percorrer o registo e o pagamento com contas de teste e registar cada passo, para que um PM possa apontar para o momento exato em que algo falha.
Eis como isto se traduz na prática. Uma PM a trabalhar em conversão de voz para texto pediu ao Manus para fazer benchmark de mais de 10 modelos e depois escolheu um. Puxou o código do frontend através do Mono, construiu uma demonstração no nosso sistema de design e pediu ao Manus para renderizar cada cenário de utilizador como uma imagem para ela rever. Transformou a demonstração num vídeo. O plano estava suficientemente claro para que ela própria construísse a funcionalidade, incluindo a UI web e desktop.
Houve três decisões humanas ao longo do processo. Ela escolheu o modelo. A equipa de produto e design reviu a demonstração. Um engenheiro com permissões de publicação reviu o código. Há um ano, nada disto teria sido possível.
Descrevemos isto como passar de human in the loop para human on the loop. Antes, a AI fazia 70-80% de uma tarefa e as pessoas preenchiam o resto. Agora, as pessoas definem as regras, supervisionam vários agentes, verificam métodos e resultados em pontos-chave, intervêm quando necessário e assumem o resultado.
Alguns PMs entregam agora um pequeno vídeo em vez de uma especificação escrita ou mockups. Em poucos minutos, mostra o caso de uso, cada ecrã, o que cada clique faz, como se comportam os casos extremos e como tudo funciona por baixo. Para nós, design, engenharia e QA chegam mais depressa a acordo sobre o que significa "concluído", e o PM explica-o uma única vez.
(Vídeo de requisitos de produto para entrada de voz)
Hoje, cerca de metade dos nossos PMs lançam funcionalidades sozinhos, e todos os PMs já contribuíram com código. Os designers também começaram. Um PM escreveu a maior parte da interface do Manus Studio em Manus 2.0. Outro escreveu o Video Editor. Por trás de cada um destes está alguém que passou meses a ir além do que o seu papel costumava abranger. É disso que mais me orgulho.
Isto não significa que todos tenham de ser builders. Quando qualquer pessoa numa empresa consegue construir, podem ser lançadas coisas que não deveriam existir. A nossa equipa de produto faz muitas vezes uma pergunta: "Se isto demorasse um segundo e não custasse nada, lançá-lo-ias?" Por vezes a resposta é não. Continuamos a precisar de responsáveis de módulo que decidam o que é construído, o que não é e o que os utilizadores acabam por ver. Também precisamos de pessoas que mantenham infraestruturas como o Mono. Quando construir se torna fácil, decidir o que construir importa ainda mais.
7. Um colega de equipa AI dentro do fluxo de trabalho de marketing
Uma parceria de marketing passa por revisão de guião, preços, contratos, aprovações, pagamento, lançamento e revisão de resultados. Esses passos vivem em email, ferramentas de contratos, sistemas de aprovação, folhas de cálculo e plataformas de anúncios. Grande parte do trabalho consistia em mover informação entre eles, o que deixava pouco tempo para o trabalho criativo que exige julgamento.
Começámos com um pequeno problema: quando o conteúdo de um parceiro ou um anúncio era publicado, muitas vezes só sabíamos tarde. Por isso pedimos à AI que escrevesse um script que deteta quando o conteúdo é publicado. Depois quisemos dados de desempenho. Depois uma revisão de parcerias anteriores. Depois todo o fluxo de trabalho interno ficou ligado: quando um contrato é assinado ou uma aprovação é concluída, o Agent atualiza o estado e notifica quem é responsável pelo passo seguinte.
O Manus construiu tudo isto num 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 é aquilo a que chamamos um colega de equipa AI. Funciona apenas nos canais e sistemas aos quais a equipa o ligou, com acesso restrito a este fluxo de trabalho.
Eis o que faz:
•Gere a sua própria fila. Muitas pessoas enviam-lhe mensagens ao mesmo tempo, por isso fala com todos numa única sessão de "receção" e entrega tarefas a sessões paralelas. Decide se uma mensagem lhe diz respeito e, em seguida, se deve interromper o trabalho atual ou esperar. Ele próprio propôs estas regras durante o desenvolvimento, e nós revimo-las antes de as manter.
•Aprende com contexto reencaminhado. Uma mudança de estratégia implicava antes uma reunião e um documento escrito. Agora, o nosso responsável de marketing reencaminha a discussão e diz: "Aprende isto."
•Mantém à vista objetivos de longa duração. Numa ocasião, colegas numa thread do Slack onde tinha sido adicionado não se recordavam em que ponto estava um projeto. Sem ser mencionado, respondeu: "B ainda está em testes. Devemos esperar pelos resultados de A antes de olhar para B?"
•Confirma factos com outras equipas. Depois de lançarmos o rigging de modelos 3D, perguntou à equipa de produto o que era suportado. Descobriu que o rigging cobre sete categorias, incluindo peixes, cobras e quadrúpedes, pelo que as nossas descrições se mantiveram precisas.
Os colegas de equipa incluem-no agora nas revisões de guião e de preços, porque leu os nossos registos de parcerias anteriores. A decisão continua a ser das pessoas.
O site interno também pode melhorar a partir dos seus próprios utilizadores, incluindo o Agent. Quando o Agent encontra uma dificuldade, envia um pedido através de um endpoint de feedback. Isso abre uma tarefa de desenvolvimento no Manus através das Automations do Manus 2.0, e um engenheiro revê a alteração antes de ser lançada. Está a funcionar há cerca de uma semana. Precisamos de muitos mais casos antes de podermos confiar nele.
Então, o que faz a equipa? Três coisas continuam com eles. Tomam e assumem todas as decisões importantes. Lidam com casos que o Agent ainda não viu e ensinam-lhe o que fazer ou a quem perguntar. E redirecionam-no sempre que a sua análise aponta para um novo ângulo.
8. Interromper-nos menos uns aos outros
Em todas estas equipas, muitas perguntas já não exigem interromper ninguém.
Pergunta primeiro ao agente. Um colega de equipa criou um bot do Slack no Mono que corre num computador na nuvem e responde na thread. Quem mais o usa são os não-engenheiros. Como funciona esta funcionalidade? Onde está esta string? Isto já foi lançado? Já não precisam de encontrar primeiro o responsável.
Abre a sessão em vez de pedir uma atualização de estado. O progresso de um engenheiro costumava viver nos seus próprios chats de AI, invisível assim que se desconectava. Por isso, construímos uma funcionalidade interna que permite aos membros de um projeto verem as sessões uns dos outros e pedirem para se juntar. Um engenheiro pode construir a maior parte de uma funcionalidade com o agente, e depois um PM junta-se à mesma sessão para ajustar espaçamentos, estilos e copy. Publicar na sessão de outra pessoa requer a sua aprovação, e ainda estamos a definir as permissões.
(Exemplo ilustrativo: como um engenheiro, um PM e um designer trabalham numa só sessão. Não é uma alteração real de preços.)
O objetivo não é falar menos uns com os outros. É interromper menos uns aos outros.
Decide apenas o que precisa de ser decidido. O nosso maior utilizador de AI mantém uma sessão principal com uma única tarefa: listar o que precisa da sua decisão, com uma recomendação para cada ponto. Quando o Slack fica agitado, ele mantém-se fora e pergunta: "O que é que preciso de decidir agora mesmo?"
Eu faço algo semelhante. Tenho mais de 20 to-dos por dia e, como já partilhei publicamente, tenho ADHD. Começar é a parte mais difícil para mim. Agora, cada to-do vai para um projeto Manus dedicado que transforma cada um numa tarefa própria. Começa o que consegue. Quando tem dúvidas, pede-me contexto e qual o PM que deverá ser responsável. Depois, usando o acesso que lhe dei ao meu Slack, Gmail e Notion, 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 é apenas sobre eficiência. Agora passo muito menos tempo do meu dia ansioso sobre por onde começar, o que é enorme a nível pessoal.
9. Vale o custo?
Gastamos muito em AI e acompanhamos esse gasto de perto. Não o usamos para avaliar o desempenho de ninguém. Usamo-lo para avaliar o próprio gasto: está a compensar agora ou a preparar-nos para mais tarde?
Eis o que achamos que isto nos compra, e para onde esperamos que o custo vá:
•Compra-nos tempo e atenção. À medida que uma equipa cresce, a coordenação consome a atenção de todos. A AI protege a atenção de cada pessoa e dá-lhes uma apropriação mais completa do seu trabalho. E continuamos a contratar.
•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 secção 4 corre nos modelos mais fortes a que conseguimos aceder. O colega que lidera a produtividade dos programadores chama-lhe o nosso gasto com melhor relação custo-benefício.
•O custo deverá cair através do produto. Mais do nosso desenvolvimento acontece agora no Manus Studio, o nosso próprio produto, pelo que os nossos dados de utilização mostram-nos onde se desperdiçam tokens. As correções entram no produto, pelo que também devem tornar o Manus mais eficiente para os utilizadores. Esperamos que os custos atuais caiam substancialmente à medida que os modelos ficam mais baratos e removemos desperdícios. Isto é uma convicção, não uma promessa!
10. O que ainda não está a funcionar
Há menos interrupções, mas a atenção está mais fragmentada. Alguém que costumava lidar com quatro ou cinco coisas por dia pode agora fazer avançar 20 ou 30 ao mesmo tempo. Cada mudança significa recarregar o contexto. A AI expande o que as pessoas conseguem fazer e também as empurra a fazer mais. Uma PM disse-me que, sempre que uma tarefa está a correr, não consegue resistir a iniciar outro agente. Fazer mais coisas não é o objetivo. Estamos a tratar isto como um problema a resolver, não um ritmo a celebrar.
A informação está mais dispersa. O nosso responsável de produto costumava saber de cada alteração e porque foi feita. Agora, às vezes, tira uma captura de ecrã a um problema e pergunta ao Mono: "Quem mudou isto?" Tem piada, mas a pergunta é real. Quando toda a gente tem poder para mudar o produto, quem é responsável pelo todo?
As permissões de partilha precisam de um redesenho. Quando o trabalho pode ser partilhado e transferido, e os agentes participam em mais das nossas conversas, temos de decidir o que é aberto e o que precisa de aprovação.
As nossas correções ainda são básicas. Por agora, um agente supervisiona os outros e reporta apenas o que está bloqueado e o que precisa de uma decisão humana. Sabemos que isto pode ser melhor.
11. O que estamos a construir a seguir
Estes problemas apontam para trabalho de produto que outras equipas provavelmente também irão necessitar. Não planeámos estas funcionalidades antecipadamente. Surgiram de problemas com que nos deparávamos repetidamente.
•Sessões como espaços de trabalho partilhados. Uma pessoa levanta um problema, um designer propõe uma solução, um engenheiro constrói-a e um PM executa-a, tudo no mesmo lugar.
•Trabalho que se move entre dispositivos e pessoas. As máquinas locais e na nuvem permanecem ligadas, para que o trabalho possa continuar quando as pessoas se ausentam.
•Agents que encontram opções em que as pessoas não tinham pensado. Um agent a trabalhar 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 experimentar isto connosco primeiro e depois levá-lo aos utilizadores.
12. O que as pessoas fazem agora
O engenheiro com uma série de sessões de agent abertas não é apenas uma história sobre eficiência. É uma mudança naquilo em que uma organização assenta. As empresas costumavam mover informação através de papéis e hierarquia. O que uma pessoa conseguia fazer dependia de quantas pessoas e recursos conseguia mobilizar. Agora passamos um pouco de tempo a dar contexto e ferramentas à AI, e mais tempo a fazer julgamentos e tomar decisões. Cada vez mais, é um agent que nos traz um problema. Decidir o que fazer em relação a isso continua a ser o nosso trabalho.
Já brincámos com isso: se o Manus consegue fazer tanto, porquê vir ao escritório? Deixemos os agents resolverem. Mas as questões importantes continuam a precisar de pessoas para as levantar, discutir e decidir. Por exemplo, o que conta como um bom produto? Ou, exagerando um pouco: construir um grande produto com receita real que continue a empurrar os limites da AI, ou ir pela margem? A AI não sabe qual queremos. Nós sabemos. A cultura e a confiança nascem de trabalharmos as coisas em conjunto, dia após dia e nos momentos que importam. É esse o alicerce sobre o qual assenta o trabalho em cada sessão.
Portanto, por agora, aqui está a nossa resposta. Na nossa experiência enquanto organização AI-native, o papel das pessoas não diminuiu. Tornou-se mais focado nas áreas em que podem ter maior impacto: definir o problema, avaliar a qualidade, decidir o que vale a pena fazer, assumir o resultado.
É também por isso que continuamos a contratar. As competências e o discernimento das pessoas estão no centro desta forma de trabalhar — e isso não vai mudar tão cedo.
Enquanto escrevo isto, fico curioso por saber o que esta publicação diria daqui a um ano. Cada empresa tem objetivos, estruturas e cultura diferentes, por isso pode não haver uma resposta padrão nem uma forma final. Mas para uma empresa que constrói agents, perceber como as pessoas e a AI trabalham em conjunto não é opcional. Faz parte do trabalho. Vamos continuar nessa jornada e continuaremos a partilhar o que aprendemos.
Uma nota sobre os números. Os valores apresentados nesta publicação provêm de registos internos. As dimensões das equipas e os números de entregas dos PM referem-se ao final de outubro. Alguns pontos são estimativas ou a experiência de uma pessoa, e não medições.
