Você encontra um bug numa biblioteca, usa um agente para investigar e chega a uma alteração que resolve o seu caso. Ao abrir a pull request, você oferece duas coisas ao projeto: a descrição da falha e um código que o mantenedor pode examinar, questionar e modificar.
Eu ainda prefiro receber essa contribuição. Não espero que a implementação enviada esteja pronta para ser incorporada, mas gosto da possibilidade de trabalhar sobre uma tentativa de solução. Você pode ter encontrado um caminho que vale discutir, mesmo quando a correção final precisa ser diferente.
Entendo também o mantenedor que prefere uma issue detalhada e faz a implementação com os próprios agentes. O tempo gasto recuperando o problema e corrigindo uma proposta mal testada pode superar o trabalho de resolver a falha dentro das convenções da biblioteca.
Direto ao ponto
Minha preferência é receber código acompanhado da explicação do problema e de um teste que demonstre a correção. A pull request permite discutir uma implementação concreta. O mantenedor continua livre para aproveitá-la parcialmente, propor outro caminho ou recusá-la por incompatibilidade com os usos existentes.
O código proposto permite examinar a tentativa de solução
Uma issue descreve o comportamento encontrado. A pull request acrescenta uma tentativa de explicar esse comportamento pelo código: você alterou uma condição, tratou uma entrada que não estava prevista ou mostrou um teste que falha na versão atual.
Essa tentativa pode revelar uma dúvida que o relato inicial não resolvia. Ao examinar a função alterada, o mantenedor consegue discutir por que você seguiu aquele caminho e apontar uma consequência que ficou fora do seu teste. A conversa ganha uma implementação específica para comparar com o comportamento pretendido.
É essa possibilidade que me interessa. Receber o código não obriga a manutenção a incorporá-lo como veio, nem transforma a primeira correção numa solução definitiva. O trabalho proposto pode ser ajustado durante a revisão, preservando a investigação que você já fez.
Uma contribuição assim também exige que você entenda o resultado do agente. Quando o mantenedor pergunta por que determinada condição mudou, a resposta precisa explicar a relação com o bug. Repetir a descrição gerada pela IA não resolve uma dúvida sobre um comportamento que você ainda não conferiu.
A descrição do problema continua necessária
Considere uma função de busca que retorna um valor nulo quando não encontra registros. Sua aplicação tenta percorrer o resultado como uma lista e apresenta um erro. Você altera a biblioteca para devolver uma lista vazia, e a mesma chamada deixa de falhar.
O teste demonstra que a mudança atende ao seu caso, mas ainda falta discutir o comportamento esperado da biblioteca. Outra aplicação pode verificar o retorno nulo para mostrar uma mensagem de ausência de resultados. A alteração proposta muda a resposta que essa aplicação já sabe interpretar.
Uma descrição útil permite acompanhar esse raciocínio: a entrada usada, a resposta recebida e a ação que falhou na sua aplicação. O mantenedor pode então avaliar a proposta de mudar o retorno ou orientar você a tratar o valor nulo no código que chama a biblioteca.
Os testes de código gerado por IA com Laravel permitem conferir a relação entre entrada e comportamento esperado. Numa contribuição externa, essa relação precisa estar compreensível também para a manutenção, que examina a correção junto dos compromissos já assumidos pelo projeto.
Por isso, a combinação de descrição e implementação faz sentido para mim. O código oferece um caminho para resolver a falha, enquanto o relato preserva o problema que motivou a contribuição. A conversa pode continuar mesmo quando a manutenção escolhe outra implementação.
Uma proposta inadequada também cria trabalho
Na minha participação no Mautic e em outros repositórios, vejo contribuições de agentes que não fazem sentido para o projeto. Essa experiência me faz reconhecer o trabalho que chega junto de uma pull request, inclusive quando a alteração parece pequena.
Você pode enviar uma correção misturada com mudanças de formatação e reorganização de funções. Para avaliar o bug, o mantenedor precisa distinguir a alteração necessária das preferências de organização introduzidas pelo agente. Uma explicação que apenas informa que o problema foi resolvido não permite fazer essa separação.
O trabalho de revisão de pull requests com IA inclui recuperar a falha, examinar as alterações e conferir os comportamentos que devem continuar funcionando. Uma contribuição reduz esse trabalho quando mantém a mudança concentrada no problema e explica o teste executado.
Isso não autoriza classificar toda contribuição feita com IA como inadequada. O agente pode auxiliar a investigação e escrever uma boa implementação. Você ainda precisa conferir o que está enviando e participar da conversa técnica sobre a correção.
A preferência do mantenedor também merece ser considerada
Desenvolver os meus sistemas, trabalhar para clientes e manter código aberto são situações diferentes. Numa biblioteca usada por outras aplicações, a alteração será incorporada a projetos que o mantenedor não acompanha diretamente. A compatibilidade precisa ser examinada antes da distribuição.
Receber somente issues permite que ele conduza a implementação com seus agentes, testes e convenções. Continuo preferindo receber código, mas compreendo essa escolha quando a revisão das propostas externas ocupa o tempo disponível para a manutenção.
Você ainda pode colaborar com um projeto nesse formato. Um caso reproduzível informa uma falha que o mantenedor talvez não encontre nas aplicações que usa. A descrição conserva sua utilidade mesmo quando o código é escrito internamente.
Tenho preferido descrever melhor as tarefas destinadas à IA no meu próprio trabalho. Para estudar esse desenvolvimento com agentes, a formação de Vibe Coding está disponível pelo plano IA Makers. A investigação do problema precisa acompanhar a prática de gerar e conferir a implementação.
Confira o formato aceito pelo repositório
Para investigar uma alteração do seu projeto com orientação técnica ao vivo, o Desenvolvimento Colaborativo da Dev Side Studio oferece uma sessão prática. Você opera o editor e o terminal enquanto trabalhamos na compreensão da falha e na correção.
Na próxima contribuição, confira o formato aceito pelo repositório. Havendo espaço para enviar código, mantenha a descrição do problema junto do teste e da implementação, para que a manutenção consiga discutir o que você encontrou e o caminho que está propondo.
Continuo essa conversa no Diário do VibeCoder sobre pull requests e issues. Para acompanhar outros conteúdos sobre desenvolvimento, consulte o catálogo de vídeos da Promovaweb.
