Como decidir quais tarefas não delegar à IA

Os limites da IA na programação não aparecem apenas quando o código é difícil. Eles aparecem quando a tarefa exige decidir uma intenção ambígua, assumir impacto relevante ou aceitar um resultado que não pode ser verificado com segurança antes de chegar ao usuário.

Por isso, a pergunta prática não é se a inteligência artificial consegue gerar uma alteração plausível. É se aquela tarefa pode ser delegada, precisa de condução humana ativa ou deve ser conduzida por pessoas com a IA apenas como apoio.

Quando uma tarefa parece simples, mas ainda exige julgamento

Antes de acionar um agente de programação, a equipe pode perceber que uma tarefa aparentemente pequena ainda tem algo fora do lugar. A alteração toca uma regra pouco escrita, afeta uma jornada sensível ou depende de uma decisão de produto que ninguém formulou claramente.

Esse desconforto é um sinal útil. Ele mostra que a dificuldade da tarefa não está somente na implementação. Está na responsabilidade de interpretar o que deve ser verdadeiro.

Uma mudança de texto em uma tela pode ser simples se a mensagem aprovada já existe. A mesma mudança pode ser delicada se altera a expectativa do usuário sobre um prazo, uma cobrança, uma permissão ou uma exceção operacional. Uma refatoração pode ser segura quando preserva comportamento testado. Pode ser arriscada quando muda o limite entre domínios, redistribui responsabilidades e torna uma falha mais difícil de diagnosticar.

A condução humana não deve entrar apenas no fim, como uma revisão tardia de algo que a IA já decidiu na prática. Ela precisa aparecer antes da execução quando a tarefa mistura intenção incompleta, consequência relevante e verificação fraca.

Na triagem, a pergunta muda: a IA vai executar uma decisão já tomada ou ocupar uma decisão que a equipe ainda não organizou?

Use três critérios: ambiguidade, impacto e verificação

Uma forma objetiva de escolher tarefas assistidas por IA é classificar o trabalho por três critérios: ambiguidade, impacto e possibilidade de verificação.

Ambiguidade é a falta de clareza sobre a intenção ou a regra. Ela aparece quando a descrição usa expressões como “melhorar”, “ajustar”, “evitar problemas”, “tratar exceções” ou “deixar mais flexível”, sem dizer qual comportamento deve mudar e qual deve permanecer igual. Também aparece quando há conhecimento tácito em produto, atendimento, operação ou arquitetura.

Impacto é a consequência da mudança. Pode ser técnico, operacional, reputacional, de segurança, de receita, de confiança do usuário ou de continuidade do serviço. Não é apenas o tamanho do diff. Uma linha de código pode carregar mais impacto do que uma reorganização ampla de componentes visuais.

Verificação é a capacidade de confirmar que o resultado está correto. Isso pode envolver testes automatizados, revisão por pares, logs, comparação antes e depois, critérios de aceite, ambientes de homologação ou aceite de uma área responsável. O DORA descreve integração contínua como integração frequente ao código principal, acompanhada de construção e testes automatizados. Na triagem proposta aqui, isso ajuda a revelar problemas cedo, mas não substitui a decisão humana quando o comportamento esperado ainda não está claro.

A pergunta de triagem fica simples:

A intenção está escrita de modo que uma pessoa diferente tomaria a mesma decisão?
O impacto da mudança é baixo, reversível e isolado?
Existe uma forma objetiva de verificar o resultado antes de expor usuários ou sistemas críticos?

Se as três respostas forem favoráveis, a tarefa tende a ser delegável para IA com revisão. Se uma ou duas respostas forem incertas, a IA pode ajudar, mas uma pessoa deve conduzir a interpretação. Se as três forem frágeis, a tarefa deve ser conduzida por pessoas, com IA como apoio para pesquisa, comparação, simulação ou documentação.

Tarefas delegáveis são pequenas, independentes e testáveis

Tarefas delegáveis são aquelas em que a IA pode executar boa parte do trabalho sem assumir a decisão central. Elas costumam ter escopo pequeno, resultado esperado explícito, baixo impacto e verificação clara.

Exemplos típicos incluem:

Atualizar nomenclatura já aprovada em componentes isolados.
Adicionar testes para comportamento já definido.
Corrigir uma inconsistência visual com critério objetivo.
Ajustar um adaptador simples quando contrato, entrada e saída estão claros.
Remover código morto identificado e coberto por testes.

O DORA recomenda trabalhar em unidades pequenas, independentes e testáveis para obter retorno mais cedo sobre mudanças e revisar hipóteses com menos atraso. A mesma orientação alerta para a dificuldade de revisar e integrar mudanças grandes geradas com IA, especialmente quando chegam como blocos amplos e difíceis de decompor DORA.

A aplicação prática não é transformar toda tarefa em microtrabalho mecânico. É evitar que um agente receba uma missão ampla demais, produza uma alteração grande demais e obrigue a equipe a revisar intenção, arquitetura, regra de negócio e teste ao mesmo tempo.

Uma tarefa delegável deve caber em uma frase verificável. Por exemplo: “alterar o rótulo do botão X para o texto aprovado Y nos arquivos A e B, sem mudar comportamento, mantendo os testes atuais”. Nesse caso, a IA pode apoiar a execução porque a decisão já foi tomada. A revisão humana confirma aderência ao escopo, qualidade do código e ausência de efeitos colaterais aparentes.

O limite aparece quando a descrição vira: “melhorar o fluxo de cobrança para reduzir dúvidas”. Essa frase pode ser uma boa intenção de produto, mas ainda não é uma tarefa delegável. Antes, alguém precisa separar hipóteses, regras, mensagens, eventos, exceções e critérios de verificação.

Esse cuidado conversa com decisões mais amplas de organização do trabalho assistido por IA. Um roadmap de IA conectado a oportunidades reais ajuda a priorizar onde a tecnologia entra. Na engenharia, a mesma lógica precisa descer para o nível da tarefa: o que está claro, o que é arriscado e o que pode ser provado.

Tarefas assistidas precisam de uma pessoa conduzindo a interpretação

Há uma faixa intermediária em que a IA é útil, mas não deve conduzir sozinha. São tarefas em que parte do trabalho é implementável, mas a interpretação exige julgamento humano contínuo.

Isso inclui regra de negócio ambígua, ajuste em fluxo usado por clientes, refatoração que altera limites de domínio, mudança com dependências entre áreas ou correção de defeito cujo diagnóstico ainda não está fechado.

Nessa faixa, a pessoa conduz a tarefa em ciclos curtos. Ela formula a hipótese, seleciona o contexto, pede alternativas, compara efeitos e decide o próximo passo. A IA pode gerar código, sugerir testes, levantar arquivos relacionados, resumir histórico e explicar impactos possíveis. Mas a direção continua humana.

A engenharia de contexto ajuda nesse ponto. A Anthropic define engenharia de contexto como a seleção e manutenção das informações disponíveis ao modelo durante a inferência, incluindo instruções, ferramentas, dados externos e histórico, dentro de uma janela limitada Anthropic. Em termos práticos, isso significa que o resultado da IA depende do que foi colocado diante dela e do que ficou de fora.

Quando a tarefa depende de conhecimento disperso, a condução humana precisa decidir qual contexto importa. Não basta despejar documentos no agente. É preciso dizer qual regra prevalece, que arquivos delimitam o escopo, quais comportamentos não podem mudar e em que ponto a IA deve parar para pedir decisão.

Uma boa instrução para essa faixa não é apenas “implemente”. Ela se parece mais com:

“Mapeie os pontos afetados antes de alterar código.”
“Liste dúvidas de regra de negócio antes da implementação.”
“Proponha opções e riscos, sem modificar arquivos ainda.”
“Implemente somente a alternativa aprovada.”
“Pare se encontrar comportamento não documentado ou teste contraditório.”

A revisão humana, aqui, não é só uma etapa no pull request. Ela é condução durante o raciocínio. Isso reduz o risco de que uma decisão ausente seja preenchida pelo caminho mais provável, mais conveniente ou mais coerente com um contexto incompleto.

Tarefas humanas usam IA como apoio, não como executora principal

Algumas tarefas não devem começar como execução autônoma de IA. Não porque a IA seja inútil, mas porque o trabalho central é decidir, negociar trade offs e assumir consequências.

Entram nessa faixa decisões arquiteturais difíceis de reverter, alterações que afetam confiança do usuário, mudanças sem forma clara de verificação, incidentes sem diagnóstico confiável, exceções de regra com impacto operacional e decisões que exigem alinhamento entre produto, engenharia e liderança.

A documentação do GitHub sobre agentes do Copilot descreve recursos com ambientes e permissões distintos e ressalta supervisão humana e revisão das saídas GitHub. Essa orientação é compatível com uma prática simples: quanto maior a autonomia concedida a uma ferramenta, mais explícitos precisam ser escopo, permissão, parada e revisão.

Em tarefas humanas, a IA pode apoiar de várias formas:

Resumir alternativas arquiteturais já documentadas.
Comparar prós e contras de opções formuladas pela equipe.
Gerar perguntas para uma reunião de decisão.
Criar rascunhos de testes depois que o comportamento esperado foi definido.
Ajudar a documentar a decisão tomada.

Mas a IA não deve escolher sozinha a exceção de negócio, definir a tolerância a risco, decidir uma mudança de experiência sensível ou transformar uma preferência implícita em regra do sistema.

Aqui vale uma frase incômoda: delegar execução quando a decisão ainda não existe é uma forma elegante de esconder desgovernança.

A maturidade não está em proibir IA nessas situações. Está em impedir que ela vire atalho para decisões que deveriam ser explícitas. A liderança que trata IA como parte da estratégia precisa conectar capacidade técnica a responsabilidade decisória, como em uma estratégia de inteligência artificial conectada ao negócio, e não apenas à automação de tarefas soltas.

Exemplo fictício: trocar a regra de cobrança de atraso

Imagine um produto digital que precisa ajustar a comunicação e o cálculo de atraso em uma rotina de cobrança. Este exemplo é fictício e serve apenas para aplicar os critérios. Os efeitos esperados seriam hipóteses a medir, não resultados ocorridos.

A primeira subtarefa é renomear mensagens da interface. O texto aprovado já existe, os componentes afetados são conhecidos e a alteração não deve mudar comportamento. A ambiguidade é baixa, o impacto é limitado e a verificação é direta por revisão visual e testes existentes. Essa tarefa pode ser delegável para IA com revisão humana.

A segunda subtarefa é ajustar o cálculo de dias de atraso. Agora há mais risco. A regra parece objetiva, mas pode depender de fuso horário, feriado, horário de fechamento, reprocessamento ou divergência entre sistemas. A IA pode ajudar a mapear pontos de cálculo, sugerir testes e implementar uma alternativa. Mas uma pessoa precisa conduzir a interpretação, confirmar a regra e exigir testes que cubram os cenários relevantes. É uma tarefa assistida por IA com condução humana ativa.

A terceira subtarefa é decidir exceções para clientes específicos. Aqui a questão principal não é código. É política de produto e operação. Quem pode receber exceção? Em quais condições? Como registrar a decisão? Quem assume o impacto se dois usuários em situações parecidas forem tratados de forma diferente? Antes de qualquer geração de código, pessoas precisam definir a regra, o risco e a forma de verificação. A IA pode ajudar a organizar opções e documentar a decisão, mas não deve conduzir a execução principal.

O ponto do exemplo não é classificar cobrança como assunto sempre sensível. É mostrar que uma mesma iniciativa contém tarefas de naturezas diferentes. Algumas são delegáveis. Outras exigem condução. Outras precisam de decisão humana antes de virar backlog técnico.

É por isso que a triagem deve acontecer antes de acionar a IA, não apenas na revisão final.

Checklist de triagem antes de executar com IA

Use este checklist antes de entregar uma tarefa a um agente de programação ou a qualquer fluxo de código assistido por IA. Os critérios abaixo são uma proposta prática para a decisão da equipe.

Ambiguidade

Baixa condução humana: a intenção está escrita, o comportamento esperado é objetivo e não há disputa sobre a regra.

Condução humana ativa: a intenção geral existe, mas há exceções, linguagem vaga ou dependência de contexto de negócio.

Condução humana principal: a tarefa exige decidir o que deve ser verdadeiro, não apenas como implementar.

Impacto

Baixa condução humana: a mudança é reversível, isolada e afeta uma área de baixo risco.

Condução humana ativa: a mudança toca fluxo usado por clientes, integrações ou regras com consequência operacional.

Condução humana principal: a mudança pode afetar receita, segurança, conformidade, confiança do usuário ou continuidade do serviço.

Possibilidade de verificação

Baixa condução humana: há testes automatizados, critério de aceite claro ou comparação objetiva antes da entrega.

Condução humana ativa: parte do resultado pode ser testada, mas a validação final depende de revisão de regra, produto ou operação.

Condução humana principal: a equipe não consegue provar o acerto da mudança antes de expor usuários ou sistemas críticos.

Contexto disponível

Baixa condução humana: instruções, arquivos relevantes e restrições estão disponíveis para a tarefa.

Condução humana ativa: o contexto existe, mas precisa ser selecionado, explicado ou protegido contra interpretações erradas.

Condução humana principal: o conhecimento necessário está disperso, tácito ou depende de decisão ainda não tomada.

Critério de interrupção

Baixa condução humana: a IA pode prosseguir se mantiver o escopo e os testes continuarem passando.

Condução humana ativa: a IA deve parar ao encontrar regra não documentada, dependência inesperada ou divergência entre testes e intenção.

Condução humana principal: a tarefa não deve começar como execução de IA enquanto decisão, risco e verificação não estiverem definidos.

Antes da execução, a tarefa precisa entrar em uma destas três faixas: delegável para IA com revisão, assistida por IA com condução humana ativa ou conduzida por pessoas com IA apenas como apoio.

Se a tarefa não tem intenção clara, impacto entendido e forma de verificação, ela não está pronta para delegação autônoma. Primeiro, a equipe precisa decidir que tipo de responsabilidade aquela tarefa carrega antes de entregar o teclado para a IA.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

Para continuar esta leitura

Como encerrar uma tarefa de desenvolvimento com IA

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.