A IA aprendeu com o código legado humano

Numa PME, uma regra pode sobreviver durante anos à pessoa que a criou. Fica numa função, numa folha de cálculo ou na memória de alguém que mudou de equipa. Quando chega a altura de automatizar o processo, ninguém sabe explicar porque existe aquela exceção. É fácil pedir a um assistente de programação que avance. Também é fácil proibir a ferramenta e deixar tudo como está.

As duas opções evitam a pergunta que interessa: quem conhece o processo e consegue reconhecer uma solução errada? O código confuso já existia antes dos modelos de linguagem. Foi escrito por pessoas com pressa, informação incompleta e, por vezes, sem registar o motivo das decisões. A IA aprendeu padrões produzidos por pessoas. Escreve depressa, mas não recupera o contexto que a empresa perdeu.

• O código legado humano já continha duplicações, atalhos e regras sem responsável.

• A IA pode produzir uma resposta plausível sem saber se a regra serve a operação.

• Recusar toda a assistência desperdiça usos possíveis; aceitar código incompreendido transfere o risco para a empresa.

• Cada decisão em produção precisa de alguém que a consiga explicar e assumir.

A IA aprendeu padrões, não a história das regras

Os modelos aprendem relações entre instruções e exemplos de código. Isso não lhes dá acesso às razões por detrás das regras de uma empresa. Também não podemos afirmar que um modelo específico foi treinado com determinado repositório legado: os dados de treino não são divulgados em detalhe para todos os modelos.

O código produzido por pessoas inclui bons exemplos e práticas menos cuidadas. Há respostas copiadas de fóruns, funções repetidas com pequenas diferenças e comentários sobre processos que entretanto mudaram. Um modelo pode sugerir algo útil, mas também reproduzir um padrão que parece correto e ignora uma exceção importante.

Imagina uma validação que parece redundante. Pode ter sido acrescentada depois de um fornecedor enviar ficheiros num formato inesperado. Quem conhece o histórico percebe o motivo. Um modelo só o saberá se alguém lhe der esse contexto. Sem ele, pode remover a validação, mantê-la sem necessidade ou criar uma regra que entra em conflito com outra.

Por isso, culpar a ferramenta por todo o código mau simplifica o problema. Às vezes a sugestão está errada. Noutras, o pedido omitiu informação essencial. A rapidez facilita a propagação do erro, mas não explica como a regra ficou sem dono.

A sensação de velocidade não prova que houve ganho

A assistência de IA não garante que uma tarefa fique pronta mais depressa. Um estudo publicado pela organização de investigação METR em 2025 acompanhou 16 programadores experientes em 246 tarefas reais de repositórios open source que já conheciam. Nas tarefas realizadas com as ferramentas de IA avaliadas, demoraram, em média, mais 19% do que sem elas.

O resultado não prova que a IA atrase todos os programadores, nem que todas as ferramentas tenham o mesmo efeito. Refere-se àquele grupo, às tarefas estudadas e às ferramentas usadas. É útil porque revela uma diferença entre a impressão de produtividade e o tempo medido até à conclusão do trabalho.

O que correu mal foi contar a assistência como ganho antes de medir o percurso completo. Pedir uma sugestão demora. Ler, corrigir, testar e integrar também. Se a equipa conta linhas geradas em vez de alterações validadas, está a medir atividade, não entrega. Para a operação, interessa o resultado correto, integrado e aceite por quem conhece o processo.

Recusar a IA por princípio deixa o legado onde está

Uma proibição total não documenta regras, não resolve a dependência de uma única pessoa e não torna seguro um sistema antigo. Pode ainda levar colaboradores a usar ferramentas sem orientações claras sobre dados, revisão ou publicação.

Há tarefas delimitadas em que um modelo pode ajudar: explicar uma função antiga, sugerir casos de teste ou preparar uma alteração pequena e reversível. A explicação tem de ser confirmada por alguém que conheça o sistema. E os testes precisam de critérios definidos fora do código gerado. Se a IA interpreta mal o pedido e cria testes a partir da mesma interpretação, os testes podem passar enquanto a operação continua errada.

Recusar a ferramenta pode fazer sentido quando não há forma segura de proteger os dados ou de reverter uma alteração. Recusá-la sem avaliar a tarefa não melhora o controlo. A decisão deve depender do uso concreto, não de uma preferência geral a favor ou contra a IA.

A dependência começa quando ninguém consegue contestar o resultado

A dependência aparece quando a equipa deixa de conseguir explicar o código que aceita. Um agente pode interpretar mal uma regra, escrever código coerente com essa leitura e apresentar testes que a confirmam. O sistema parece consistente. Ainda assim, pode bloquear uma encomenda válida, alterar uma fatura ou enviar uma mensagem errada a um cliente.

A revisão técnica verifica aspetos do software. Não decide se a operação deve aceitar uma exceção, nem se o resultado é adequado para o cliente. Essa decisão precisa de alguém do negócio que conheça o processo e possa aprovar ou travar a alteração. Se ninguém consegue explicar o que acontece quando o caso normal falha, a revisão do código não preenche essa lacuna.

A responsabilidade não desaparece porque a primeira versão foi escrita por uma máquina. Quem aprova uma alteração tem de conseguir identificar o que ela muda, que situações cobre e como se volta atrás. Se isso não é possível, ainda não há base para a pôr em produção.

A ferramenta só entra depois de o processo estar dominado

Antes de escrever código ou ligar um agente, tens de perceber o trabalho real. Fala com quem decide e com quem executa. A direção pode conhecer o objetivo, mas não ver as exceções que surgem numa segunda-feira de manhã, quando falta um dado ou um fornecedor muda o formato de um ficheiro.

Na Seamless Doubt, começamos por ouvir quem faz o trabalho e perceber as exceções antes de propor tecnologia. Se o processo ainda não pode ser explicado, dizemos que não está pronto para uma automação. Pode ser preciso organizar a informação primeiro, ou começar com uma ferramenta simples. Um agente só faz sentido quando há maturidade para o supervisionar.

Essa ordem também evita construir uma solução maior do que o problema. Primeiro, confirma-se que o processo é compreendido. Depois, define-se quem valida o resultado e o que acontece quando a automação falha. Só então se escolhe a ferramenta adequada.

A velocidade de escrita não compensa a falta de controlo da operação

Um programador pode usar IA sem depender dela, desde que saiba explicar o código entregue, detetar quando a sugestão contraria o processo e assumir a revisão. A ferramenta pode poupar trabalho numa parte da tarefa. Não pode assumir a decisão de negócio.

Se a pessoa que revê não consegue contestar o resultado, a empresa está a aceitar uma alteração que não compreende. Nesse caso, escrever mais depressa só faz a dúvida chegar mais cedo à produção. A pergunta útil não é quantas linhas a IA gerou, mas quem consegue dizer que a alteração está certa e porquê.

Conclusão

Escolhe um processo pequeno e reversível. Regista o que o inicia, as exceções conhecidas, quem valida o resultado e como interromper ou desfazer a automação. Se não houver acordo sobre o que é um resultado correto, não peças à IA para decidir por todos.

Quando testares uma ferramenta, mede o tempo até à entrega validada, incluindo revisão, correções e integração. Se não consegues explicar o processo nem identificar quem aprova a alteração, adia a automação e clarifica primeiro as decisões. A vantagem está em saber quem responde por cada regra, mesmo quando a máquina ajudou a escrevê-la.