Nossos colegas de equipe de IA participaram do nosso evento retrô

Desenvolvemos software retrospectivo, então o quadro de retrospectiva da nossa equipe é um lugar bastante comum: Iniciar, Parar, uma coluna de ações pendentes, as discussões habituais de sexta-feira. Na semana passada, ele ganhou alguns novos colaboradores. Seis dos cartões não foram escritos por nenhum ser humano — eles foram preenchidos pelos agentes de IA com os quais trabalhamos todos os dias, resumindo os atritos observados em suas próprias sessões de trabalho conosco.

Vamos ser precisos sobre o que isso significa, porque a forma como nos expressamos é importante. Não se trata de uma IA presente na reunião: nenhum bot facilitando a reunião, nenhum recurso de IA resumindo os cartões dos participantes. Os agentes que realizam o trabalho de verdade em nossa equipe (aqueles que escrevem código, editam conteúdo, realizam auditorias) compareceram à cerimônia da mesma forma que qualquer colega de equipe: com seu próprio relato de como o trabalho transcorreu. Participantes, não facilitadores; a reunião continuou sendo nossa.

Isso também não foi um truque. A ideia surgiu em uma de nossas próprias retrospectivas: alguém comentou que os documentos de integração estavam desatualizados (de novo) e outra pessoa mencionou que um agente havia sinalizado exatamente isso para ela no meio de uma sessão naquela manhã, de passagem, antes que o contexto desaparecesse da tela. O agente já sabia disso; nada em seu sistema indicava que valia a pena registrar essa observação. Por isso, nas últimas semanas, temos conduzido um experimento conosco mesmos: a prática é a que descrevemos em como coletar feedback de seus agentes de IA. Ao final de cada sessão de trabalho substancial assistida por IA, o agente escreve uma breve entrada estruturada de retrospectiva sobre seu próprio trabalho: o que deu certo, o que demorou, quanto cada atraso custou, um rótulo de causa raiz por item e uma solução proposta. Os registros se acumulam nos repositórios onde o trabalho foi realizado. Quando já havia um número suficiente deles, um processo complementar os lia todos e registrava os padrões recorrentes diretamente em nosso quadro de retrospectiva, com um prefixo[AI retro]para que ninguém confundisse o autor.

Veja o que nossos mais novos colegas de equipe disseram sobre trabalhar conosco.

O que eles descobriram

A manchete que eles destacaram era sobre eles mesmos. O cartão principal dizia: “Comece a verificar antes de agir — erros de execução dos agentes representam 38% do atrito (o dobro da segunda causa mais comum); o custo recorrente está em atribuir uma causa, enviar ou redirecionar antes de verificar o código em produção, os dados ou o estado do branch.” A maior fonte de atrito em nosso trabalho assistido por IA, segundo os próprios agentes, eram os próprios agentes, especificamente o hábito de agir com base em um estado presumido do mundo, em vez de verificar primeiro o estado real. Aceitamos essa honestidade de qualquer colega.

O maior problema relacionado ao trabalho em equipe ultrapassou todos os limites que uma pessoa não ultrapassaria. Erros no Git e no estado dos ramos durante o trabalho com agentes simultâneos surgiram em oito sessões, em dois repositórios: bases desatualizadas, destinos de ramos não lidos, um agente movendo um ramo que outro estava usando, um PR redirecionado sem verificação. Nenhuma sessão isoladamente teria alcançado uma posição tão alta no ranking; cada caso era motivo apenas de um encolher de ombros e alguns minutos perdidos. Mas, quando avaliado em todas as oito sessões, esse tema se destacou de forma incontestável.

Fomos pegos fazendo envios com verificações incompletas. Quatro sessões em que algo foi enviado ou mesclado após uma verificação mais restrita do que a que a CI realmente executa: uma simples verificação de tipos em vez da compilação completa, testes específicos em vez da suíte de testes. Duas vezes em um único repositório, no mesmo dia.

E os cartões mais incômodos não tinham nada a ver com o trabalho em si; tratavam-se de falta de acompanhamento. Um cartão observava que uma lacuna na convenção de testes havia permitido que uma falha reproduzível passasse despercebida por duas rodadas de revisão, e que o documento de correção havia sido proposto no dia anterior e nunca redigido. Outro cartão observava que o mesmo impasse na ferramenta já havia custado duas sessões, “sem que nenhuma correção definitiva tivesse sido entregue entre elas”. Um terceiro: o mesmo padrão de aumento gradual dos requisitos, três sessões consecutivas, “cada uma observando que o problema se repetia desde a última”. Acontece que o agente se lembra do que dissemos que faríamos.

As duas coisas que valem a pena observar

Primeiro: nada disso era visível para ninguém. Isso não é uma falha de atenção; é a própria natureza do problema. O atrito nas sessões de IA é crônico e de menor gravidade, por isso nunca dá origem a uma análise pós-incidente e desaparece assim que a sessão termina. Cada um de nós havia absorvido sua parcela e seguido em frente. A classificação (esse padrão é o que mais custa à equipe) só existe na visão agregada, e a visão agregada só existe porque as entradas eram comparáveis: mesmo esquema, mesmo pequeno conjunto de rótulos de causa raiz, cada relato citando uma sessão datada. Essa é a ideia de agregação no centro do guia que acompanha este post, e é a parte que mais queríamos testar em nós mesmos.

Segundo: os agentes não culparam ninguém, nem mesmo a si mesmos, de forma genérica. As anotações seguem duas regras que acabaram se revelando mais importantes do que esperávamos. Os itens de atrito descrevem a lacuna e o custo dela, nunca quem a causou: sem nomes, sem “relatório de X”. E “o agente cometeu um erro” é um rótulo residual, usado apenas quando as informações fornecidas eram genuinamente adequadas, e é exatamente por isso que o número de 38% chamou nossa atenção: ele resistiu a essa disciplina. O resultado parecia uma boa contribuição retrospectiva: específico, com evidências citadas, sem atribuição de culpa e um pouco constrangedor para todos igualmente.

O que a assembleia decidiu

Decidimos implementar todas as três ações propostas, cada uma no nível indicado. A regra “confirmar o ramo ativo e o status do PR antes de fazer alterações” será incluída na documentação do agente de cada repositório, uma correção na documentação relacionada ao tema das oito sessões. O gancho pré-push que executa a compilação e os testes equivalentes à CI será implementado nos repositórios que foram prejudicados por verificações parciais — uma correção de ambiente, para que não dependa da memória de ninguém. E o documento sobre a convenção de testes que foi “sinalizado no dia anterior e nunca foi escrito” está sendo elaborado, usando a falha que passou despercebida como exemplo prático.

Sem grandes reorganizações, sem novos processos: três correções do tamanho de um ticket, com responsáveis definidos. A modéstia é deliberada: toda a aposta dessa prática é que pequenas correções, direcionadas ao nível certo e efetivamente verificadas no próximo ciclo, se acumulam. Se essas três correções vão se manter é exatamente o que a verificação de adoção do próximo briefing nos dirá; o mesmo mecanismo que nos pegou da última vez será o responsável por nos avaliar nisso.

Ainda é cedo, e estamos deixando isso bem claro. Mas saímos daquela reunião retrospetiva mais interessados em nossos próprios padrões de trabalho do que estávamos há algum tempo — e um pouco competitivos com um colega que nem sequer se cansa.

As notas de rodapé sinceras

Este é nosso primeiro resumo sintetizado, com dados de semanas, não de meses; por isso, estamos tratando as classificações como uma forma de alocação de atenção, e não como uma contabilidade. Os custos indicados nas entradas são estimativas do próprio agente e estão identificados como tal. As afirmações mais ousadas da prática (de que os rótulos permanecem consistentes entre os avaliadores, de que a linha de tendência realmente se curva após a implementação das correções) são experimentos que estamos realizando, e não suposições que estamos fazendo, e publicaremos os resultados independentemente do desfecho.

Mas o principal resultado já apareceu: um conjunto de padrões que ninguém da equipe conseguia identificar individualmente, classificados, comprovados e apresentados na cerimônia em que as pessoas responsáveis pelas correções já estavam presentes. O Feedback Flywheel de Rahul Garg inclui em sua lista de cadência “um item da pauta na retrospectiva de sprint existente: o que funcionou com a IA neste sprint?”. Agora podemos afirmar que esse item da pauta se torna consideravelmente mais interessante quando seus colegas de equipe de IA apresentam seus próprios itens.

Experimente com sua própria equipe

Tudo o que utilizamos é gratuito e está documentado no guia: como funcionam as entradas, os rótulos de causa raiz, as regras de “nunca registrar” (sem segredos, sem dados de clientes e nunca nada que identifique uma pessoa) e o item de 15 minutos da pauta do facilitador, além das duas habilidades que implementam as etapas de captura e síntese. Funciona com qualquer agente compatível e um arquivo de texto; nosso produto é apenas um dos locais onde os resultados podem ser armazenados, não um requisito.

No próximo ciclo, a verificação de aprovação do briefing nos dirá se, desta vez, realmente elaboramos aquele documento de testes. Nós avisaremos vocês. E eles também.

Já experimentou? Discorda? Estamos falando sério quando dizemos que queremos que discutam conosco: ai-discussion@TeamRetro.com.