Esta é a primeira edição de um relatório que pretendemos atualizar todos os trimestres: o que as pessoas pedem aos agentes de programação de outras pessoas para fazer, e o que acontece quando o fazem. Os dados provêm da beta privada do muti, cobrem os trinta dias até 6 de setembro de 2026 e são reduzidos. Cinquenta e oito pedidos, seis máquinas, dez salas. Publicamo-los ainda assim porque mais ninguém está a publicar nada sobre agentes partilhados, e números pequenos e honestos superam números grandes imaginados.
Todos os valores são agregados. Sem texto dos pedidos, sem nomes, sem nomes de salas.
Os números
Cinco números dos primeiros trinta dias, com os respetivos denominadores.
O que achamos que significam
Um terço de pedidos de não proprietários é elevado para uma beta sem qualquer marketing. Os proprietários convidaram pessoas e essas pessoas utilizaram o agente. A partilha é o produto e aconteceu espontaneamente.
As aprovações são rápidas quando são raras. Nove aprovações em cinquenta e oito pedidos, respondidas numa mediana de 38 segundos. Esse é o comportamento pretendido pelo design: as quatro ações que exigem sempre pausa e os modos de permissão mantêm os prompts escassos, para que os prompts que restam recebam atenção real. Consulte quatro ações que um agente deve sempre perguntar antes de executar.
O Bash pede permissão. A maioria das aprovações foi para comandos de shell. Leituras e edições de ficheiros decorreram maioritariamente sob acceptEdits; os momentos em que foi necessária intervenção humana foram comandos. Isso coincide com aquilo para o qual os modos de permissão foram concebidos.
As falhas são sobretudo falhas de runtime, não de permissões. Dez pedidos falharam; na timeline aparecem como falhas de testes, ferramentas em falta e um timeout de runtime. Nenhuma se deveu a uma aprovação recusada.
Quarenta e um segundos é a tarefa mediana. Até agora, pedem-se aos agentes partilhados coisas pequenas e específicas: reexecutar isto, resumir aquilo, exportar estes ficheiros. Refatorações longas são raras e partem quase sempre do proprietário.
O que os números não significam
- Não são representativos. Seis máquinas, a maioria nossas e de amigos nossos. A proporção de pedidos de não proprietários cairá à medida que a base de proprietários crescer, antes de voltar a subir.
- Conclusão não é correção. «Done» significa que o runtime terminou sem erros; se o resultado foi bom ou não, não é medido aqui.
- A latência de aprovação depende do proprietário. Nove pontos de dados, vários proprietários, um único número. Encare-o mais como «menos de um minuto» do que como «38 segundos».
O que iremos adicionar
Próxima edição: categorias de pedidos (código / documentos / dados / ficheiros), percentagem de pedidos com anexos e latência de aprovação por hora do dia. Tudo agregado, tudo publicado com denominadores.
Método
Os valores provêm das mesmas tabelas em que o produto assenta: pedidos, aprovações de ferramentas, membros de salas e eventos da timeline, contabilizados em dias UTC. Sem amostragem. Salas e agentes sujeitos a soft-delete são excluídos das contagens «atuais» e incluídos nas contagens de eventos que «ocorreram». O modelo de auditoria está descrito em o que um registo de auditoria deve registar.
Perguntas frequentes
Posso obter os dados em bruto? Não. Os agregados são tudo o que publicamos; os pedidos são privados em relação às suas salas.
Porquê publicar com n = 58? Porque a alternativa é não publicar nada e porque indicar o denominador permite aos leitores avaliar o contexto. A próxima edição será maior ou explicará por que razão não é.
Com que frequência? Trimestralmente, com as mesmas métricas para que possam ser comparadas, além dos novos pontos anunciados na edição anterior.
Se quiser entrar na próxima edição, dê uma sala ao seu agente.
Publicado a