Como conduzir um piloto de processo com IA

Um piloto de desenvolvimento amplificado começa com uma hipótese verificável: a mesma unidade de trabalho pode passar pelo fluxo atual e pelo fluxo assistido por inteligência artificial sem perder qualidade. A comparação precisa observar se o processo inteiro entrega uma mudança pequena, revisável, testável e compreensível, sem empurrar risco para a revisão, para a integração ou para quem vai manter o código depois.

Escolha uma mudança pequena, independente e comparável

O primeiro erro de um piloto de desenvolvimento amplificado por IA é escolher uma tarefa que funciona bem em demonstração, mas mal em comparação. Se a tarefa é grande demais, mistura objetivos ou depende de decisões abertas, qualquer conclusão ficará frágil. A IA pode parecer rápida na geração de código, enquanto o time perde tempo entendendo escopo, revisando efeitos colaterais ou corrigindo algo que não deveria ter entrado no mesmo lote.

A unidade de trabalho do piloto precisa caber no fluxo normal do time. Ela deve ter comportamento esperado, critério de aceite, testes possíveis e impacto limitado. Uma alteração pequena em uma regra de cálculo, uma validação de interface administrativa ou um ajuste de integração já conhecida costuma ensinar mais sobre o processo do que uma refatoração ampla.

A orientação do DORA sobre lotes pequenos é um bom apoio aqui: mudanças pequenas, independentes e testáveis permitem retorno mais cedo e revisão de hipóteses com menos acoplamento. A mesma fonte alerta para a dificuldade de revisar e integrar grandes mudanças geradas com IA. Esse ponto é decisivo para o piloto. Se a IA aumenta o tamanho da mudança, ela pode estar acelerando a escrita e piorando a revisão.

Uma regra prática: escolha uma alteração que outro desenvolvedor consiga revisar sem reconstruir mentalmente o sistema inteiro. Se a tarefa só funciona porque uma pessoa específica conhece atalhos, dependências e exceções não documentadas, o piloto medirá improviso, não processo.

Esse recorte também evita sobrepor a decisão deste piloto com discussões mais amplas de organização do processo, tratadas no guia de desenvolvimento amplificado por IA. Aqui, a pergunta é mais estreita: o fluxo assistido preserva qualidade quando comparado ao fluxo atual pela mesma régua?

Registre como o fluxo funciona antes da IA

Antes de inserir IA, registre o fluxo atual com precisão suficiente para comparar. Não é necessário mapear toda a engenharia da empresa. É necessário entender como aquela mudança sai de uma demanda para código integrado.

O registro deve capturar etapas, responsáveis e artefatos usados. Onde a demanda nasce? Que especificação existe? Quem decide o escopo? Que arquivos ou documentos o desenvolvedor consulta? Como o pull request é aberto? Quem revisa? Quais testes rodam? O que bloqueia a integração ao código principal?

Esse mapa evita uma comparação injusta. Sem linha de base, a equipe tende a comparar uma execução assistida por IA com uma lembrança otimista do processo anterior. Ou o inverso: culpa a IA por problemas que já existiam no fluxo, como critérios de aceite ambíguos, testes frágeis ou revisão concentrada em poucas pessoas.

O registro também precisa incluir esperas. Muitas vezes, o gargalo não está na implementação, mas na autorização de escopo, na descoberta de contexto, na fila de revisão ou em uma construção quebrada que ninguém prioriza. Se o piloto medir apenas o tempo entre “comecei a codar” e “abri o pull request”, ele pode ignorar o custo real da mudança.

Um bom mapa do fluxo antes da IA responde a perguntas simples:

Qual era a intenção da mudança?
Quais informações estavam disponíveis antes da implementação?
Quais decisões foram tomadas por pessoas e onde ficaram registradas?
Quais testes foram executados antes da integração?
Que tipo de comentário apareceu na revisão?
Que retrabalho surgiu depois da revisão ou da integração?

Esse registro não precisa virar burocracia. Ele precisa ser comparável.

Desenhe o fluxo amplificado sem remover julgamento humano

No fluxo amplificado, a IA deve ter papel explícito. Ela pode ajudar a levantar hipóteses, localizar arquivos relevantes, sugerir testes, rascunhar implementação, explicar trechos de código ou propor alternativas. Mas geração não é autorização. Sugestão não é decisão.

A documentação do GitHub sobre agentes do Copilot descreve recursos de agentes com ambientes e permissões distintos e ressalta supervisão humana e revisão das saídas. A implicação para o piloto é direta: defina o que a IA pode fazer, o que ela pode apenas sugerir e o que exige decisão humana antes de seguir.

Também vale separar IA como ferramenta de apoio de IA como substituta de fluxo. Um piloto ruim entrega a uma ferramenta uma demanda ambígua, aceita uma mudança grande e espera que a revisão humana corrija tudo no fim. Um piloto melhor divide responsabilidades:

Pessoa responsável pela demanda define o comportamento esperado.
Pessoa desenvolvedora seleciona contexto, limites e arquivos relevantes.
IA apoia investigação, geração ou revisão preliminar.
Revisão humana avalia intenção, legibilidade, risco e aderência aos testes.
Integração contínua valida construção e testes automatizados antes da entrada no código principal.

Esse desenho se conecta ao tema da revisão humana no fluxo assistido por IA, mas não depende de uma estrutura sofisticada para começar. O piloto precisa apenas deixar claro quem decide, quem revisa e quais saídas da IA não podem ser aceitas automaticamente.

No piloto, registre quais sugestões foram aceitas, quais foram rejeitadas e qual pessoa ficou responsável pela decisão.

Defina critérios de qualidade antes de medir velocidade

Velocidade é sedutora porque parece objetiva. Mas tempo de implementação isolado não mede qualidade do processo. Uma mudança pode ser escrita rápido e custar caro na revisão. Pode passar em testes insuficientes e quebrar entendimento de domínio. Pode economizar minutos de codificação e consumir horas de explicação depois.

Por isso, os critérios de qualidade precisam vir antes da medição. Para um piloto curto, use uma régua simples:

Unidade de trabalho: a mudança continua pequena, independente e testável?
Contexto fornecido: quais instruções, arquivos, decisões e histórico foram disponibilizados à IA?
Revisão humana: a revisão ficou mais clara, equivalente ou mais difícil?
Testes e integração: os mesmos testes aplicáveis continuaram rodando e falhas bloquearam avanço?
Retrabalho: correções surgiram antes ou depois da integração?
Compreensão da mudança: outro desenvolvedor consegue explicar a alteração e seus limites?

A Anthropic define engenharia de contexto como 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. Para o piloto, isso significa que o contexto usado pela IA deve ser tratado como parte do processo, não como detalhe invisível.

Se uma pessoa escolhe arquivos, cola instruções, omite decisões e depois corrige mentalmente a saída, o resultado pode depender mais da habilidade individual do que do fluxo. O piloto só se torna útil quando a equipe consegue observar que contexto foi fornecido, que hipótese foi aceita e que decisão continuou humana.

Esse cuidado conversa com práticas de engenharia de contexto para equipes de desenvolvimento, mas aqui o critério é operacional: se o resultado depende de conhecimento implícito que só uma pessoa tinha, não escale o piloto ainda.

Compare antes e depois com a mesma régua

Imagine um exemplo fictício. Uma equipe mantém um sistema interno de gestão de pedidos e escolhe uma mudança pequena em uma regra de cálculo de desconto. A regra já existe, os critérios de aceite são conhecidos e há testes automatizados para parte do comportamento.

No fluxo atual, uma pessoa desenvolvedora lê a tarefa, consulta a regra existente, altera a implementação, adiciona ou ajusta testes, abre um pull request e aguarda revisão. No fluxo amplificado, a equipe mantém a mesma tarefa e usa IA para sugerir casos de teste, localizar arquivos prováveis e rascunhar uma implementação. A pessoa desenvolvedora revisa o contexto, aceita ou rejeita sugestões, ajusta o código e abre o pull request. Nos dois fluxos, a revisão humana e a integração contínua permanecem obrigatórias.

A comparação não deve perguntar apenas “qual foi mais rápido?”. Pergunte:

A alteração assistida continuou no mesmo tamanho ou cresceu porque a IA sugeriu melhorias fora de escopo?
Os testes sugeridos cobriram o comportamento esperado ou apenas confirmaram o caminho feliz?
A revisão humana conseguiu entender a intenção sem depender de explicações longas do autor?
A construção e os testes automatizados tiveram o mesmo peso de bloqueio nos dois fluxos?
O retrabalho apareceu antes da integração ou foi deslocado para depois?
Outro desenvolvedor conseguiu explicar por que a regra mudou, onde mudou e o que não foi alterado?

A definição de integração contínua pelo DORA envolve integração frequente ao código principal, com construção e testes automatizados. A orientação também afirma que corrigir uma construção quebrada deve ter prioridade sobre novas mudanças. No piloto, isso é uma linha vermelha: se a equipe ignora uma construção quebrada para preservar a sensação de velocidade, o experimento deixa de medir qualidade.

A mesma régua protege contra dois vieses. O primeiro é dar desconto ao fluxo com IA porque ele é novo. O segundo é exigir da IA uma perfeição que o fluxo atual nunca entregou. O piloto não precisa provar superioridade. Precisa revelar onde há amplificação real, onde há deslocamento de custo e onde há risco novo.

Interrompa o piloto quando a qualidade depender de heroísmo

Um piloto útil também define sinais de parada. Sem isso, a equipe tende a seguir porque a ferramenta impressiona, porque alguém investiu energia na adoção ou porque a demonstração inicial foi boa. Mas demonstração sedutora não é valor operacional.

Interrompa ou redesenhe o piloto quando a mudança ficar grande demais para revisão comum. Esse é um sinal forte de perda de controle. A IA pode sugerir ajustes relacionados, melhorias de estilo, mudanças em nomes, reorganizações e testes adicionais. Algumas sugestões podem ser boas. Mesmo assim, se entram no mesmo lote sem decisão explícita, o piloto começa a misturar objetivos.

Outro sinal é contexto inconsistente. Se a IA recebe instruções diferentes a cada tentativa, se usa arquivos desatualizados ou se ignora decisões de arquitetura relevantes, o problema não é apenas da ferramenta. É do fluxo que não sabe oferecer contexto verificável. Antes de ampliar, ajuste especificação, documentação mínima e limites da tarefa.

Também pare quando testes frágeis virarem desculpa para revisão heroica. A revisão humana é indispensável, mas não deve ser o único mecanismo de qualidade. Quando a pessoa revisora precisa descobrir comportamento esperado, validar escopo, interpretar código opaco e ainda compensar ausência de teste, o piloto está apenas transferindo custo.

Há outros sinais claros:

A revisão vira formalidade porque “foi gerado pela IA”.
A construção quebrada deixa de bloquear novas mudanças.
O ganho aparece na implementação, mas o retrabalho aumenta depois.
A equipe não consegue explicar a mudança sem recorrer ao autor original.
A IA passa a decidir arquitetura, segurança, comportamento de produto ou uso de dados sensíveis sem autorização humana explícita.

Nesses casos, insistir no piloto não aumenta maturidade. Só normaliza exceção.

Transforme o resultado em decisão de processo

O produto final do piloto não é uma declaração de amor ou rejeição à IA. É uma decisão de processo. Ao fim da comparação, a liderança técnica deve conseguir escolher um caminho entre três opções:

Manter o fluxo atual e não ampliar o uso de IA naquela classe de tarefa. Essa pode ser a decisão correta se o ganho de implementação for pequeno, se a revisão ficar mais difícil ou se o retrabalho apenas mudar de lugar.
Ampliar o uso da IA em etapas específicas. Por exemplo, usar IA para sugerir testes, explicar código legado ou levantar hipóteses de impacto, mantendo implementação e decisões de escopo com condução humana mais próxima. Essa decisão faz sentido quando a IA melhora uma parte do fluxo sem degradar revisão, integração e compreensão.
Redesenhar parte do processo. Talvez o piloto revele que o problema não está na IA, mas na falta de especificação, em decisões não registradas, em testes lentos ou em revisão concentrada. Nesse caso, o próximo passo não é comprar mais ferramenta nem proibir ferramenta. É ajustar o sistema de trabalho.

Para fechar, use este checklist como critério de decisão:

Se a IA aumenta o tamanho da alteração ou mistura objetivos, não escale.
Se o resultado depende de contexto implícito, melhore o contexto antes de repetir.
Se a revisão fica opaca, reduza o lote e explicite decisões.
Se testes e integração perdem força de bloqueio, invalide a comparação.
Se o retrabalho reaparece depois, não conte a implementação rápida como ganho.
Se outro desenvolvedor não consegue sustentar a mudança, o fluxo ainda não preservou qualidade.

Um piloto de desenvolvimento amplificado só deve avançar quando a comparação mostra onde houve ganho, onde houve deslocamento de custo e quais condições precisam permanecer. Comece por uma classe pequena de mudança, registre o fluxo atual, rode o fluxo assistido com julgamento humano explícito e compare qualidade antes de falar em escala.

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

Leituras para continuar

Fontes

Para continuar esta leitura

Como coordenar tarefas paralelas de agentes de código

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.