Desenvolvimento com IA: processo, contexto e verificação

Desenvolvimento de software com inteligência artificial falha quando uma tarefa rápida demais chega à revisão sem contexto, limite e evidência. Quando a IA gera código rápido, a equipe precisa enxergar com clareza o que foi pedido, qual contexto foi usado, onde a mudança começa e termina, e como ela será verificada antes de entrar no código principal.

O ciclo mínimo é simples de nomear e difícil de praticar: contexto suficiente, execução em unidades pequenas e verificação humana e automatizada antes da integração.

Onde a tarefa assistida por IA perde controle

O problema aparece em uma cena conhecida: um pull request chega com muito código, uma explicação convincente e testes parciais. A descrição parece razoável. A alteração compila em algum ambiente. A pessoa revisora entende a intenção geral, mas não consegue responder com segurança a perguntas básicas.

O que exatamente foi solicitado? Quais arquivos a IA consultou? A solução mudou apenas o comportamento pedido ou aproveitou para reorganizar trechos vizinhos? Os testes cobrem a regra de negócio ou apenas confirmam que a nova implementação não quebra o caminho feliz? Quem decidiu que o risco restante era aceitável?

A IA aumenta a capacidade de execução, mas não aumenta automaticamente a maturidade do processo. Ela pode produzir mais alternativas, mais código e mais explicações em menos tempo. Isso é útil. Também pode deslocar o gargalo para a revisão, para a integração e para a reconstrução mental do que aconteceu.

Esse deslocamento concentra risco na revisão final, que passa a acumular descoberta de escopo, intenção, arquitetura, teste, impacto e decisão. Quando isso acontece, a equipe não está usando IA para amplificar desenvolvimento. Está usando IA para antecipar trabalho que ainda não foi bem definido.

A diferença importa. Desenvolvimento assistido por IA não deve ser organizado como uma fila de prompts. Prompt é uma interface. Processo é a forma como a organização decide, executa, confere e aprende com uma mudança.

Em equipes de engenharia, isso muda a pergunta principal. Em vez de perguntar apenas “qual ferramenta vamos usar?”, vale perguntar: “qual ciclo impede que código plausível entre sem contexto, sem limite e sem verificação suficiente?”.

Esse ciclo precisa ser pequeno o bastante para caber no dia a dia e explícito o bastante para sobreviver à pressa.

O ciclo mínimo: contexto, execução e verificação

Um processo de desenvolvimento com IA pode ficar sofisticado rapidamente. Pode envolver agentes, ambientes isolados, políticas de permissão, automações de teste, revisão assistida e documentação viva. Tudo isso pode ter lugar. Mas o desenho operacional precisa começar por três responsabilidades.

• Contexto: definir o que a IA precisa saber e respeitar antes de alterar código.
• Execução: transformar a tarefa em mudanças pequenas, independentes e testáveis.
• Verificação: confirmar comportamento, escopo e integração antes de levar a mudança adiante.

Esse ciclo não depende de tratar a IA como autora autônoma nem como simples autocomplete. Ele funciona porque separa responsabilidades que muitas equipes misturam quando estão sob pressão.

Contexto não é despejar o repositório inteiro na ferramenta. É selecionar informação relevante para reduzir adivinhação. Execução não é aceitar a maior resposta possível. É limitar a alteração para que ela possa ser revisada. Verificação não é procurar defeito depois que tudo está pronto. É decidir se aquela mudança merece avançar.

Essa separação também ajuda a liderança técnica a distribuir melhor o julgamento humano. A pessoa não deve entrar apenas no fim, cansada, diante de uma alteração grande demais. O julgamento humano aparece antes, ao formular a tarefa. Durante, ao interromper desvios. Depois, ao confirmar se a mudança deve ser integrada.

Para organizações que estão estruturando uma adoção mais ampla de inteligência artificial, esse recorte conversa com uma decisão anterior: conectar uso de IA a prioridades de negócio, não apenas a entusiasmo tecnológico. Esse ponto aparece no guia da dooop sobre estratégia de inteligência artificial conectada ao negócio, mas aqui a unidade de análise é menor: uma mudança de software.

A pergunta prática é: esta tarefa está pronta para ser amplificada por IA ou ainda precisa ser refinada por pessoas?

Contexto: o que a IA precisa saber antes de alterar código

Engenharia de contexto é a seleção e manutenção das informações disponíveis ao modelo durante a inferência. A definição da Anthropic inclui instruções, ferramentas, dados externos e histórico, sempre dentro de uma janela limitada. Essa limitação é relevante: se tudo não cabe, alguém precisa escolher o que entra.

No desenvolvimento de software com IA, contexto é uma decisão de engenharia, não um anexo burocrático. Ele orienta o modelo sobre o que a tarefa pretende mudar, quais restrições existem e quais caminhos não devem ser seguidos.

Uma tarefa minimamente preparada deve explicitar alguns elementos.

• Objetivo da mudança: qual comportamento deve ser criado, corrigido ou preservado.
• Escopo permitido: quais módulos, arquivos ou camadas podem ser alterados.
• Restrições técnicas: padrões já adotados, dependências que não devem ser introduzidas, limites de arquitetura e compatibilidade.
• Critérios de aceite: como a equipe saberá que a mudança funcionou.
• Riscos conhecidos: partes sensíveis, casos de borda e impactos esperados.
• Evidências úteis: testes existentes, decisões de arquitetura, logs, exemplos de uso ou documentação interna.

A curadoria é tão importante quanto a quantidade. Um contexto grande, contraditório e sem prioridade pode piorar a decisão. O modelo pode seguir uma instrução antiga, interpretar uma exceção como regra ou propor uma solução coerente com um trecho irrelevante do histórico.

Por isso, a equipe precisa tratar contexto como um artefato vivo da tarefa. Se durante a execução aparece uma regra de negócio desconhecida, a resposta não é pedir para a IA “tentar mesmo assim”. A tarefa volta para refinamento. Se a restrição arquitetural não está clara, a equipe registra a decisão ou aponta onde ela já está documentada. Se a mudança depende de comportamento não testado, isso precisa aparecer no critério de verificação.

Essa disciplina não exige criar uma documentação enciclopédica antes de cada alteração. Exige reconhecer que a IA vai preencher lacunas quando elas existirem. Algumas lacunas são aceitáveis. Outras transferem risco demais para uma saída que parece segura apenas porque está bem escrita.

Há um critério simples: se uma pessoa nova na equipe não conseguir entender o objetivo, o limite e a forma de verificar a tarefa, a IA provavelmente também estará operando com contexto insuficiente.

Esse ponto se conecta ao diagnóstico de capacidade organizacional. Antes de escalar ferramentas, vale saber se a organização consegue formular problemas, priorizar riscos e manter informações úteis. O tema aparece em outro nível no conteúdo sobre maturidade em IA. No ciclo de desenvolvimento, maturidade aparece como clareza operacional.

Desenvolvimento de software com IA exige execução em unidades pequenas

Depois do contexto, vem a execução. Aqui a tentação é pedir muito de uma vez: corrigir o defeito, melhorar o nome das funções, refatorar um serviço antigo, atualizar testes e reorganizar uma dependência. A IA pode aceitar. O problema é que a equipe depois precisa revisar tudo junto.

O DORA recomenda unidades de trabalho pequenas, independentes e testáveis para obter retorno sobre mudanças e revisar hipóteses mais cedo. A mesma orientação alerta para a dificuldade de revisar e integrar grandes mudanças geradas com IA. Esse ponto não transforma IA em problema por si só. Ele mostra que tamanho e mistura de objetivos continuam sendo fatores críticos.

Uma unidade pequena não é apenas uma alteração com poucos arquivos. É uma alteração com uma hipótese verificável. “Corrigir a regra de arredondamento no cálculo de frete para pedidos com cupom” é mais revisável do que “melhorar o checkout”. “Adicionar teste para preservar comportamento atual antes da mudança” é diferente de “reescrever a suíte de testes”.

O tamanho certo depende do sistema, da equipe e do risco. Mas alguns sinais indicam que a tarefa está grande demais para uma execução assistida por IA.

• A descrição contém vários verbos de intenção, como corrigir, refatorar, otimizar e padronizar.
• A alteração cruza camadas sem explicar por quê.
• O modelo propõe mudanças em arquivos que não foram citados nem justificados.
• A revisão exige entender um novo desenho arquitetural que não fazia parte da tarefa.
• Os testes adicionados validam detalhes de implementação, mas não o comportamento esperado.

Nesses casos, a decisão correta pode ser dividir antes de gerar mais código. Uma parte investiga. Outra preserva comportamento com teste. Outra altera a regra. Outra remove dívida técnica, se ela realmente precisar ser removida. Nem tudo precisa acontecer no mesmo pull request.

Essa disciplina reduz a sedução do “já que estamos aqui”. Em desenvolvimento com IA, essa frase merece cuidado. O modelo pode executar melhorias colaterais com facilidade, mas facilidade de alteração não é autorização de escopo.

A liderança técnica tem um papel direto: proteger a unidade de decisão. Se a mudança corrige uma regra, a revisão deve conseguir decidir sobre aquela regra. Se a refatoração é necessária, ela deve ter justificativa própria. Misturar as duas coisas torna a decisão opaca.

Verificação: o que precisa acontecer antes de integrar

A etapa de verificação começa antes do botão de merge. Ela responde a quatro perguntas: a solução atende à intenção? O escopo foi respeitado? O comportamento foi testado? A base continua saudável para novas mudanças?

A documentação do GitHub descreve recursos de agentes com ambientes e permissões distintos e ressalta supervisão humana e revisão das saídas. Para o processo de engenharia, isso sustenta uma regra prática: mesmo quando a ferramenta executa tarefas em ambientes próprios, a aceitação da mudança precisa passar por revisão.

Revisão humana de código gerado por IA não deve ser uma conferência estética. Ela precisa verificar intenção. A pessoa revisora deve procurar a relação entre tarefa, contexto, alteração e evidência. Uma implementação elegante pode estar resolvendo o problema errado. Um teste passando pode estar cobrindo apenas o caminho que o modelo escolheu.

Uma sequência prática de verificação pode seguir este raciocínio.

• Ler a tarefa e confirmar o comportamento esperado antes de ler a solução.
• Comparar os arquivos alterados com o escopo permitido.
• Verificar se a mudança introduziu dependências, padrões ou atalhos não solicitados.
• Conferir se os testes automatizados cobrem o critério de aceite.
• Rodar construção e testes definidos pela equipe.
• Decidir se a mudança pode integrar, se precisa voltar para ajuste ou se deve ser descartada.

Integração contínua também entra aqui. O DORA descreve integração contínua como integração frequente ao código principal, acompanhada de construção e testes automatizados. A orientação também afirma que corrigir uma construção quebrada deve ter prioridade sobre novas mudanças. Para um fluxo com IA, isso reforça um limite: não faz sentido empilhar saídas novas sobre uma base que já não está saudável.

A verificação precisa ter critérios de interrupção. Se o agente altera arquivo fora do escopo, pare. Se a justificativa não corresponde ao diff, pare. Se a solução depende de uma regra não documentada, pare. Se o teste falha e a resposta é alterar o teste sem explicar a mudança de comportamento, pare.

Parar não é fracasso. É controle de processo.

Essa é uma das decisões mais difíceis culturalmente, porque a saída da IA cria sensação de progresso. Uma saída bem apresentada pode parecer avanço suficiente. Sem verificação, porém, a equipe empurra para depois o trabalho de confirmar comportamento, escopo e impacto.

Exemplo fictício: corrigir uma regra de desconto sem abrir uma refatoração

Considere um exemplo fictício em uma plataforma de comércio eletrônico. A equipe identifica que um cupom promocional não deve acumular com uma regra de desconto por volume. Em alguns pedidos, os dois descontos aparecem juntos. A tarefa parece simples, mas toca uma área sensível do checkout.

Uma entrada ruim para IA seria: “corrigir descontos no checkout e melhorar o código”. Essa formulação abre espaço para muitas decisões implícitas. O modelo pode reestruturar o cálculo, renomear funções, alterar ordem de aplicação, mexer em testes amplos e ainda entregar uma explicação plausível.

Uma entrada melhor separa contexto, execução e verificação.

Contexto mínimo da tarefa:

• Objetivo: quando um cupom promocional estiver aplicado, o desconto por volume não deve ser somado ao total.
• Escopo permitido: alterar apenas o componente responsável pela composição de descontos e os testes relacionados a essa regra.
• Restrição: não mudar a ordem geral de cálculo de impostos, frete ou totalização.
• Critério de aceite: pedido com cupom promocional e quantidade elegível para desconto por volume deve aplicar apenas o cupom.
• Caso de preservação: pedido sem cupom deve continuar aplicando desconto por volume quando elegível.
• Risco conhecido: alterações no checkout podem afetar cálculo exibido no resumo do pedido.

A execução deve caber em uma unidade pequena. Primeiro, a equipe pode pedir a criação ou ajuste de testes que expressem os dois comportamentos: com cupom e sem cupom. Depois, a alteração de código deve ser limitada à composição de descontos. Se a IA propuser reorganizar toda a estratégia de descontos, isso deve ser recusado ou separado em outra decisão.

A verificação também precisa ser concreta. A pessoa revisora confere se o teste falha antes da correção, quando isso for parte do fluxo da equipe. Confere se a solução não mudou imposto, frete ou totalização. Confere se a nomenclatura usada no código corresponde à regra de negócio. Confere se o diff não inclui arquivos de refatoração oportunista.

Nesse exemplo fictício, os efeitos esperados seriam hipóteses a medir, não resultados presumidos. A equipe poderia observar se a mudança ficou mais fácil de revisar, se houve menos discussão de escopo e se os testes deram segurança suficiente para integrar. Mas isso precisaria ser acompanhado no fluxo real da organização. Não deve ser declarado como ganho automático.

O ponto do exemplo não é a regra de desconto. É o limite. A IA pode ajudar a escrever o teste, localizar trechos relevantes e propor implementação. A equipe continua responsável por decidir qual problema está sendo resolvido e qual problema não será resolvido agora.

Essa decisão de não expandir escopo é uma forma de liderança técnica. Ela evita que cada tarefa pequena vire uma reforma disfarçada.

Padrão mínimo de execução para desenvolvimento com IA

O padrão abaixo organiza o ciclo contexto, execução e verificação. Ele não substitui arquitetura, revisão de segurança, testes adequados ao domínio nem critérios próprios da equipe. Serve como um filtro para decidir se uma tarefa está pronta para IA, se a execução deve continuar e se a mudança pode ser integrada.

A tarefa tem objetivo verificável?

Antes de acionar a IA, a equipe deve conseguir dizer qual comportamento precisa mudar e como saberá que a mudança funcionou. Se o objetivo não puder ser testado, observado ou demonstrado, a tarefa volta para refinamento.

Critério de decisão: se a descrição usa termos como “melhorar”, “ajustar” ou “otimizar” sem comportamento observável, ainda não está pronta.

O contexto está limitado ao que ajuda a decisão?

Incluir instruções, arquivos, regras e histórico relevantes ajuda a reduzir adivinhação. Mas contexto sem curadoria cria ruído. A pergunta não é “quanto contexto consigo anexar?”, e sim “qual informação muda a qualidade da decisão?”.

Critério de decisão: se a IA precisar adivinhar regra de negócio, arquitetura ou restrição, a tarefa não está pronta.

A mudança cabe em uma unidade pequena, independente e testável?

A execução deve produzir uma alteração que possa ser revisada sem misturar correção, refatoração e melhoria colateral. Lotes pequenos tornam a hipótese mais clara e ajudam a revisar mais cedo, em linha com a orientação do DORA sobre unidades pequenas de trabalho.

Critério de decisão: se a alteração tem múltiplos objetivos, divida antes de gerar código.

Há critério claro para interromper a IA?

A equipe deve definir sinais de parada. Mudança fora do escopo, teste quebrado, arquivo inesperado alterado, dependência nova sem justificativa ou explicação inconsistente são sinais suficientes para interromper.

Critério de decisão: se a saída amplia o problema em vez de resolver a tarefa, pare e reespecifique.

A revisão humana verifica intenção, não apenas sintaxe?

Revisão humana precisa confirmar se a solução atende ao objetivo, preserva restrições e não cria dependências desnecessárias. A supervisão não é um carimbo no fim do fluxo. É parte do desenho do processo.

Critério de decisão: se a revisão só confere estilo, formatação ou compilação, a verificação está incompleta.

A integração depende de construção e testes em estado saudável?

Antes de integrar, a mudança deve passar pela construção e pelos testes automatizados definidos pela equipe. Se a base está quebrada, novas saídas de IA podem apenas aumentar a confusão. A orientação do DORA sobre integração contínua reforça que corrigir a construção quebrada deve ter prioridade sobre novas mudanças.

Critério de decisão: se a construção quebrar, corrija isso antes de seguir com novas alterações.

Como transformar o ciclo em decisão de liderança técnica

A adoção de IA em engenharia não deve ser julgada apenas pela quantidade de código produzido. Código produzido é uma etapa. A pergunta de gestão é se a organização consegue transformar intenção em mudança verificável sem perder controle do escopo.

Na prática, isso desloca a liderança técnica para decisões de escopo, evidência e integração. Definir quais tarefas podem usar IA. Estabelecer o contexto mínimo. Limitar tamanho de alteração. Manter revisão humana com autoridade real. Não integrar sobre base quebrada. Registrar quando a tarefa voltou para refinamento e por quê.

Essas escolhas também ajudam a evitar dois extremos: bloquear IA por medo de perder controle ou liberar IA como se revisão final fosse capaz de absorver qualquer ambiguidade anterior. O critério útil é usar IA onde o processo consegue preservar decisão, rastreabilidade e integração segura.

Se a organização ainda está formulando sua agenda de adoção, vale conectar esse ciclo a uma visão mais ampla de prioridades, riscos e capacidades. O conteúdo sobre roadmap de IA pode ajudar nessa camada. Para equipes de engenharia, a primeira decisão é mais próxima: escolher uma classe de tarefas, aplicar o ciclo e observar onde o processo falha.

Para começar, defina um padrão mínimo de tarefa pronta, mudança pequena e verificação obrigatória. Depois escolha uma categoria de alteração de baixo acoplamento, aplique o ciclo e registre os pontos em que a equipe precisou parar, dividir ou reespecificar.

Se fizer sentido discutir como esse ciclo se encaixa na sua organização, converse com a dooop.

Leituras para continuar

• IA no desenvolvimento de software: processo, produto e aprendizagem

Fontes

• DORA: Working in small batches
• DORA: Continuous integration
• Anthropic: Effective context engineering for AI agents
• GitHub Docs: Responsible use of Copilot agents