Há alguns dias fechámos uma entrega com 47 commits em 24 horas, distribuídos entre backend e frontend. Foram feitos por uma única pessoa a trabalhar com um agente de códigoAgente de códigoUm agente de IA que escreve, modifica e testa código por conta própria dentro de um projeto. É um número que chama a atenção, e por isso convém dizer imediatamente que não é o mais importante.
O importante é por que razão foi possível, e o que teria acontecido se a mesma ferramenta estivesse noutras mãos.
Escrever código já não é o gargalo
Um agente de código escreve rápido, não se cansa e encadeia dezenas de alterações numa jornada. Isso não elimina o problema: desloca-o. Antes, o que era lento era produzir o código. Agora, o que é lento é saber que código é necessário e verificar se o que foi escrito faz o que deve.
Dito de outro modo: o agente define a velocidade. A direção é definida pela pessoa.
O que se multiplica
Um agente amplifica quem o dirige, nos dois sentidos.
Se conhece bem o sistema, sabe em que ordem deve fazer as coisas e reconhece um erro quando o vê, o agente converte esse conhecimento em trabalho concluído a um ritmo que antes não existia.
Se não o conhece, o agente converte as suas lacunas em código com a mesma rapidez. E fá-lo com bom aspeto, que é precisamente o que o torna perigoso.
Um exemplo, inventado mas muito reconhecível. Uma loja online decide deixar de guardar os preços com decimais e passar para cêntimos inteiros, para acabar com os desajustes de arredondamento. O agente recebe la ordem, localiza os vinte e tal ficheiros afetados e altera-os a todos numa tarde. Os tests passam. O código lê-se bem. Duas semanas depois, os descontos por percentagem começam a dar um cêntimo a menos em alguns carrinhos. Num único daqueles ficheiros, o agente arredondou antes de multiplicar em vez de depois. Ninguém viu porque os dados de teste eram valores redondos e porque a alteração tinha exatamente o mesmo aspeto que as outras vinte.
Quem conhecia esse cálculo teria pedido um teste com 19,99 € e 15 % antes de aceitar qualquer coisa. Quem não conhecia, aceitou uma alteração correta em vinte locais e errada num, com a mesma confiança nas vinte e uma.
Por isso, a frase funciona em ambas as direções: o agente multiplica o que já sabe, e também o que não sabe.
Três coisas que deve dominar quem dirige um agente
1. O que pedir. É necessário conhecer o sistema o suficiente para dividir o trabalho em passos delimitados, dá-los na ordem correta e saber quando o resultado não é o que foi pedido. Um agente responde à pergunta que lhe faz, não à que deveria ter feito.
2. O que pode tocar. As permissões de um agente devem ser mínimas e explícitas: que repositórios, que ramos, que credenciais, e se tem ou não acesso à produção. Dar acesso total "para ir mais rápido" é o caminho mais curto para converter um erro pequeno num grande.
3. Até onde chega. Nem todas as ações têm o mesmo peso. Uma alteração num ramo é revertida; uma eliminação de dados ou uma implementação mal feita, nem sempre. As ações irreversíveis são revistas por uma pessoa antes de acontecerem, sem exceções.
Como fazemos nós
Não é teoria. O nosso dia a dia com agentes tem quatro regras não negociáveis:
- O agente trabalha livremente em local e em ramos de trabalho. Não toca na produção sem que uma pessoa diga que sim, passo a passo.
- Antes de implementar, cópia de segurança do que vai ser substituído e um procedimento de rollback já escrito. Si algo falhar, restaura-se num minuto, não se improvisa.
- Os testes são executados antes de tocar em nada e voltam a ser executados no servidor depois. Se um falhar, a implementação não avança, por muita pressa que haja.
- Quando o agente diz "feito", alguém verifica se é verdade. A afirmação não é a prova.
São regras aborrecidas. Precisamente por isso funcionam.
Isto não é apenas sobre código
Tudo o que foi dito anteriormente aplica-se igualmente, ou ainda mais, aos agentes que começam a entrar nas empresas sem escrever uma única linha de código: o que responde a clientes por WhatsApp, o que regista despesas, o que altera uma marcação, o que envia um e-mail em nome de alguém. São ações sobre dados e pessoas reais, e algumas não se desfazem.
A mesma pergunta serve para todos: o que pode fazer sozinho, o que precisa de aprovação e quem a dá. No NAiOS, um agente pode propor uma cobrança, um envio ou uma alteração numa ficha, mas a ação é confirmada por uma pessoa. É o que chamamos uma empresa HITL, com la pessoa dentro do circuito. Não porque o agente seja incompetente, mas porque a responsabilidade não se delega.
Com vários agentes, ainda mais
Quando uma pessoa coordena vários agentes ao mesmo tempo, o que foi dito anteriormente deixa de ser uma boa prática e passa a ser uma condição. Um erro já não ocorre num único local nem num único momento. As permissões e os limites de cada agente são o que separa uma equipa que avança em paralelo de um problema que se propaga em paralelo.
A conclusão
Os agentes não substituem o critério; tornam-no mais valioso. A pessoa que sabe muito bem o que faz consegue em um dia o que antes demorava semanas. A que não sabe consegue o mesmo, mas com os seus erros.
A pergunta para qualquer empresa que esteja a adotar agentes não é quão mais rápido pode ir. É quem vai dirigi-los, com que permissões e com que limites. É, de facto, o que o Regulamento Europeu de IAAI Act (Regulamento Europeu de IA)Regulamento (UE) 2024/1689: a primeira lei abrangente sobre inteligência artificial, com obrigações por nível de risco chama supervisão humana, e o que pede às empresas que as suas equipas saibam fazer desde o artigo 4. Nós começamos por aí.
