Saltar para o conteúdo
SwankyForge
SwankyForge
Todos os artigos
Artigo9 min de leitura

Com um par de IA em cada repositório, automatizamos as verificações e mantemos cinco decisões humanas

Como a equipa de engenharia trabalha com assistentes de programação com IA: o que corre automaticamente em cada alteração, o que é sempre decidido por uma pessoa e o que ainda não medimos.

A maior parte do trabalho de engenharia nos nossos repositórios começa hoje com um assistente de programação com IA a escrever uma primeira versão. Nada disso vai para produção só com a palavra do assistente. Esta nota descreve a configuração tal como existe no repositório por trás deste site, porque é a que podemos mostrar publicamente. Enumera também as decisões que mantemos com pessoas e o número que ainda não lhe podemos dar.

A versão curta, se está a comprar

Somos um pequeno laboratório de dois engenheiros, com especialistas acrescentados por projeto. Um assistente de IA trabalha ao lado de ambos. Redige código, testes, documentação e relatórios de rotina. Verificações automáticas correm em cada alteração e bloqueiam as que violam uma regra. Uma pessoa lê cada alteração antes de ser integrada. Nada chega à produção nem ao público sem um sim explícito.

O que ganha com isto: os mesmos dois engenheiros cobrem mais do trabalho de rotina que as equipas pequenas tendem a saltar, como testes, documentação e verificações de lançamento. Isso deixa mais orçamento para as partes que exigem julgamento: escolher a métrica, decidir se vale a pena construir um modelo e integrá-lo no seu processo.

O que não afirmamos: um número de ganho de velocidade. Não medimos nenhum, e a evidência externa diz que os ganhos autodeclarados não são fiáveis. As últimas secções dizem o que mediríamos e o que isto significa para um cliente.

O que diz a investigação: a ferramenta não é o ganho

Quatro estudos de 2025 moldaram a forma como montámos isto.

  • O programa DORA da Google inquiriu cerca de 5.000 profissionais de tecnologia para o seu relatório de 2025. 90% usam IA no trabalho, e mais de 80% acreditam que ela os tornou mais produtivos. Ainda assim, 30% declaram pouca ou nenhuma confiança no código que ela gera. A síntese do relatório é que a IA «amplifies what's already there»: as equipas fortes melhoram, as equipas com dificuldades veem os seus problemas intensificar-se.
  • O Technology Report de 2025 da Bain concluiu que as equipas que usam assistentes de programação com IA registam ganhos de produtividade de 10–15%. Algumas empresas reportam 25–30%, mas apenas quando a IA é acompanhada de um redesenho de todo o processo. Uma razão para o primeiro número ser pequeno: escrever e testar código ocupa cerca de 25–35% do tempo entre a ideia e o lançamento.
  • O Stack Overflow Developer Survey de 2025 concluiu que 84% dos inquiridos usam ou planeiam usar ferramentas de IA, e 46% desconfiam da exatidão do resultado. A frustração mais comum foi um resultado quase certo, mas não totalmente.
  • O METR realizou um ensaio aleatorizado com 16 programadores open-source experientes em 246 tarefas reais. Com ferramentas de IA permitidas, as tarefas demoraram mais 19%. Os programadores esperavam um ganho de 24%, e depois continuavam a acreditar que tinham sido 20% mais rápidos. Os autores advertem que o resultado é específico do seu contexto: projetos open-source grandes e maduros, e programadores com experiência limitada da ferramenta usada.

Lidos em conjunto, os estudos dizem três coisas. Adotar um assistente é fácil. O ganho depende do processo à volta dele. E a impressão de ninguém sobre a sua própria velocidade é evidência. Por isso, pomos o esforço no processo (instruções, verificações e pontos de aprovação) e não na escolha da ferramenta.

O que o assistente faz no nosso repositório

Usamos o Claude Code. Cinco peças tornam o seu trabalho previsível.

Instruções de projeto. Um ficheiro na raiz do repositório diz ao assistente o que está onde, que regras são rígidas e que comandos executar. É versionado como código, por isso uma alteração às regras aparece na revisão como qualquer outra alteração. Qualquer pessoa com acesso ao repositório pode ler exatamente o que foi dito ao assistente.

Skills para tarefas recorrentes. Uma skill é um procedimento escrito curto que o assistente segue para um tipo de tarefa. Temos oito: redigir um caso de estudo com o seu registo de evidência, redigir uma nota de engenharia, redigir uma publicação para a página da empresa, gerar um perfil para uma plataforma externa, verificar texto quanto a nomes confidenciais e dados pessoais, uma auditoria só de leitura aos sinais de confiança do site, um relatório semanal de estado e a triagem de pedidos recebidos. Cada skill indica onde para. Nenhuma termina a publicar o que quer que seja.

Hooks. As ações do assistente passam por scripts que escrevemos. Depois de editar um ficheiro, esse ficheiro é analisado quanto a nomes confidenciais e dados pessoais, e uma deteção manda o assistente de volta para corrigir. Antes de poder executar um git commit ou push, uma guarda corre a análise de confidencialidade e o lint de afirmações sobre o que está prestes a sair da árvore de trabalho. Qualquer deteção bloqueia o comando. Um hook git pre-commit normal aplica as mesmas verificações aos commits feitos à mão.

CI em cada push e pull request. O pipeline corre lint, verificação de tipos e uma build, e depois três guardas:

  • a análise de confidencialidade, sobre o código-fonte, o conteúdo e o HTML gerado. Se faltar a sua configuração, falha em vez de passar em silêncio;
  • o lint de afirmações, que rejeita uma lista de superlativos e de frases de autoridade emprestada;
  • o validador de conteúdo, que recusa um caso de estudo sem registo de evidência, um desenho de referência que declare números medidos e um número da página inicial sem ligação para o caso de onde veio.

Estas regras são mecânicas de propósito. Um assistente produz texto plausível depressa, e plausível-mas-errado é exatamente a falha que os inquéritos descrevem. Uma regra que corre em cada commit não depende de ninguém, humano ou modelo, se lembrar de ter cuidado.

O pipeline de conteúdo. Tudo o que se destina ao público passa por três pastas: rascunhos, aprovado, publicado. Uma skill pode escrever em rascunhos e em mais nenhum lado. Só o responsável executa o passo de aprovação, que volta a correr as duas análises antes de mover o ficheiro. A publicação é manual: uma publicação aprovada é enviada ao responsável como texto pronto a colar, e uma nota aprovada só fica online com o próximo push aprovado para main. Esta nota seguiu esse caminho. Um assistente redigiu-a a partir dos próprios ficheiros do repositório, as análises correram sobre ela, e chegou a esta página depois de uma pessoa a aprovar.

O que nunca delegamos

Cinco decisões ficam com pessoas, seja o que for que as ferramentas consigam fazer.

  1. Acordar a métrica com o cliente. Que número define o sucesso, como é medido e que limiar conta como concluído. Escrevemo-lo no contrato antes de o treino começar. Um assistente pode enumerar métricas candidatas. Não pode saber sobre qual delas o seu negócio vai agir.
  2. Avaliar se o ML compensa. Por vezes, a resposta honesta é uma regra, um relatório ou uma mudança de processo. «Ainda não faça ML» é uma recomendação que fazemos, e é um juízo sobre a sua situação, não uma tarefa de geração de texto.
  3. Aprovar lançamentos. Um merge para main faz deploy. Nada é enviado para main sem um sim explícito do responsável, e as permissões do assistente excluem force-push.
  4. Falar com o cliente. Chamadas, respostas escritas, más notícias. Uma skill pode redigir uma resposta a um pedido; uma pessoa lê-a, edita-a e envia-a. Nenhum script contacta um lead.
  5. Decidir o que se torna público. Publicações, notas, perfis, casos de estudo e lançamentos de código. O pipeline faz da publicação um passo deliberado e não um comportamento por omissão.

O fio comum é a responsabilização. Cada uma destas decisões tem consequências pelas quais alguém tem de responder, e esse alguém tem de ser uma pessoa. Num projeto, é o engenheiro nomeado que acompanha o trabalho do início ao fim.

O que ainda não medimos

Não temos um número antes-e-depois para a nossa própria produtividade, e não vamos citar nenhum. O resultado do METR é a razão: programadores que foram 19% mais lentos acreditavam ter sido 20% mais rápidos. Uma impressão, incluindo a nossa, não é uma medição.

Se publicarmos um número, terá a mesma etiqueta de evidência que os nossos casos de estudo (medido, estimado ou ilustrativo), e virá de registos como estes, recolhidos numa janela indicada:

  • tempo entre a abertura de uma issue e uma alteração revista e integrada, para tipos de tarefa comparáveis;
  • a fração de alterações integradas revertidas ou corrigidas no prazo de 14 dias;
  • problemas detetados por hooks e CI antes do merge, face a defeitos encontrados depois;
  • tempo de revisão por alteração, porque é na revisão que o resultado de um assistente custa tempo às pessoas;
  • horas por marco face à estimativa da nossa calculadora.

Até lá, a afirmação honesta é mais restrita. As verificações correm em cada alteração, e as cinco decisões acima são tomadas por pessoas.

O que isto significa para si

Faz-se mais trabalho de rotina. Com um orçamento fixo, testes, documentação, monitorização e verificações de lançamento são o que as equipas pequenas cortam primeiro. Um assistente torna-os mais baratos de escrever, e as verificações tornam-nos difíceis de saltar.

O preço vai para o julgamento. As nossas tarifas e as horas por trás de cada função estão publicadas na página de preços, e a calculadora mostra a aritmética. As horas que mais importam são as gastas na métrica, na avaliação e na integração com o seu processo: as partes que nenhum assistente faz por nós. Se não tem a certeza de que o ML é a resposta certa, o teardown gratuito dá um primeiro veredicto em seis perguntas, e uma descoberta paga e curta resolve a questão antes de se treinar qualquer modelo.

Pode inspecionar a configuração. O repositório fica na sua organização desde o primeiro dia. Se um assistente trabalhar nele, as suas instruções e verificações ficam também nesse repositório, ao lado do histórico de cada alteração, onde as pode ler.

Faça as mesmas perguntas a todos os fornecedores. Que ferramentas de IA vão ver o seu código e os seus dados, e em que condições? Que verificações correm em cada alteração, e bloqueiam ou apenas avisam? Quem aprova um lançamento? O fornecedor mediu o seu próprio ganho de velocidade, e como? As respostas dizem-lhe se a IA no processo deles amplifica a disciplina ou a falta dela.

Fontes

Tem um processo que custa demasiado?

Fale-nos dele. A primeira chamada é gratuita e, se a IA não for a resposta, dizemo-lo.

Falar sobre a sua tarefa