Um assistente de IA pode ajudar a escrever código, explicar um sistema desconhecido, investigar uma falha ou redigir documentação. Um agente de IA pode ir um passo além e realizar várias ações em nosso nome.
Nos dois casos, é fácil se concentrar apenas no resultado imediato. O código compilou? O documento pareceu razoável? A tarefa avançou?
Há outro resultado que é fácil perder: o que a sessão nos ensinou sobre a maneira como nossa equipe trabalha.
Talvez faltasse ao assistente uma convenção importante do projeto. Talvez uma instrução fosse ambígua. Talvez um teste tenha detectado um problema tarde, ou uma revisão tenha encontrado um requisito de segurança que nunca foi documentado. Essas observações podem desaparecer quando a conversa termina, mesmo que sejam úteis na próxima vez que alguém enfrentar uma tarefa semelhante.
O modelo de IA não aprende automaticamente com uma conversa privada. A equipe ainda pode aprender com ela.
Uma sessão pode revelar diferentes tipos de lacunas
Quando algo dá errado, ajuda olhar além da correção imediata. O problema pode apontar para uma lacuna em alguns lugares:
- Contexto: O assistente não tinha as informações relevantes de versão, dependências, arquitetura ou domínio.
- Instruções: O pedido não deixou claro um comportamento ou uma restrição importante.
- Fluxo de trabalho: A ordem das atividades dificultou descobrir um problema cedo.
- Mecanismos de proteção: Um teste, uma verificação ou uma etapa de revisão não cobriu um risco importante.
Essas categorias não têm a intenção de transformar toda interação em uma investigação. São simplesmente uma maneira de fazer uma pergunta útil: onde uma pequena mudança ajudaria a próxima pessoa, ou a próxima sessão?
Às vezes a resposta é nenhum desses lugares. Um modelo pode cometer um erro, um requisito pode mudar ou um problema pode ser realmente incomum. Nem toda correção precisa se tornar uma nova regra.
Transforme uma correção em uma melhoria compartilhada
Imagine que um agente adicione um novo endpoint de API. O endpoint compila e os testes automatizados passam, mas uma revisão descobre que ele não aplica a regra de autorização usada pelo restante do serviço.
A correção imediata é adicionar a verificação que falta. A pergunta mais útil é o que permitiu que a omissão chegasse à revisão.
Se o requisito de autorização não estava no contexto do projeto, talvez ele deva estar na documentação relevante ou no guia de desenvolvimento. Se o requisito era conhecido, mas não foi mencionado na tarefa, talvez um modelo de solicitação precise torná-lo explícito. Se esse tipo de problema é importante o suficiente para ser prevenido repetidamente, um teste automatizado ou uma verificação na revisão pode ser um destino melhor.
O objetivo não é escrever um prompt mais longo toda vez que algo dá errado. O objetivo é colocar a lição onde ela possa ser mais útil.
Essa pequena distinção importa. Uma anotação pessoal ajuda uma pessoa a lembrar. Um teste, um guia conciso ou um fluxo de trabalho compartilhado pode ajudar todos que trabalham no mesmo sistema.
Mantenha o hábito pequeno
Ao final de uma sessão assistida por IA, uma pergunta costuma ser suficiente:
Aconteceu alguma coisa aqui que deveria mudar algo compartilhado?
Na maioria das vezes, a resposta pode ser não. A sessão foi bem, as verificações existentes foram suficientes e não há nada a preservar.
Quando a resposta é sim, a mudança deve acontecer enquanto a observação ainda está fresca. Pode ser uma frase em um guia do projeto, um exemplo em um modelo de tarefa, um caso de teste ou um item em uma lista de verificação de pull request.
O hábito pode se encaixar em um ponto de verificação existente, em vez de se tornar um processo separado. Pode ser uma pergunta em um modelo de pull request, um item curto em uma retrospectiva ou parte da conclusão de um trabalho.
O importante não é registrar tudo. Um prompt que funcionou uma vez por causa de uma preferência pessoal pode não ser útil para a equipe. Uma falha recorrente, uma convenção ausente ou uma restrição que ajudaria outras pessoas tem mais chances de merecer um lugar compartilhado.
Aprender sem abrir mão da responsabilidade
Documentação compartilhada e verificações automatizadas são úteis, mas não substituem o julgamento de engenharia. A documentação pode ficar desatualizada. Os testes podem deixar passar comportamentos importantes. Um sistema de IA pode produzir uma resposta que parece convincente e ainda assim está errada.
A finalidade dessa prática não é tirar a responsabilidade das pessoas. É tornar o conhecimento importante menos dependente da memória e menos sujeito a ser redescoberto pela mesma falha.
Para equipes experientes, o detalhe útil muitas vezes está no diagnóstico. O problema foi causado por falta de contexto, uma instrução pouco clara, um fluxo de trabalho ineficiente, um mecanismo de proteção ausente ou uma limitação que simplesmente deveria ser documentada? Cada resposta sugere uma melhoria diferente.
Para quem está começando a usar IA no trabalho, o ponto de partida é menor: observe uma correção recorrente e melhore um pouco um artefato compartilhado.
O modelo pode não aprender com cada interação. O sistema ao redor dele pode. Com o tempo, essas pequenas melhorias podem tornar a próxima sessão mais clara, a próxima revisão mais rápida e a próxima falha menos propensa a se repetir.