A programação por vibe mudou quem pode produzir uma aplicação com aparência funcional. Um prompt pode gerar telas, conectar uma API e montar um fluxo de trabalho plausível antes que uma equipe tradicional de engenharia tenha concluído sua primeira revisão de design.

Essa velocidade cria um novo problema de contratação e entrega: uma demonstração já não é uma evidência forte de que o software é bom. Os empregadores farão cada vez mais uma pergunta mais difícil: esse sistema criado por IA consegue comportar-se corretamente quando as entradas são confusas, as dependências falham, os utilizadores repetem ações e o modelo subjacente muda?

A resposta virá de um padrão de qualidade que se parece menos com polimento visual e mais com verificação disciplinada de software. As pessoas que se destacarão não mostrarão apenas o que uma ferramenta de programação com IA produziu. Mostrarão como o testaram, o que ele não pode fazer com segurança e como sabem que uma alteração não quebrou outra coisa.

Um benchmark é evidência, não uma pontuação numa tabela de classificação

Os benchmarks de agentes de programação de código aberto oferecem pontos de partida úteis, mas medem capacidades diferentes. O SWE-bench usa problemas reais do GitHub e instantâneos de repositórios, o que o torna relevante para trabalhos de manutenção. O Terminal-Bench testa a interação com a linha de comandos. Outros benchmarks listados, incluindo o SlopCodeBench e o ProgramBench, têm como alvo diferentes aspetos do código gerado e do comportamento dos agentes.

Esses benchmarks podem ajudar a comparar ferramentas ou estabelecer uma linha de base, mas os empregadores devem ter cuidado ao tratar qualquer pontuação isolada como prova de prontidão para produção. Um modelo que resolve problemas de repositórios ainda pode produzir uma lógica de autorização insegura. Um agente que conclui tarefas de terminal pode não conseguir preservar o estado ao longo de um fluxo de trabalho extenso. Uma aplicação web polida pode passar numa demonstração do caminho feliz e, ainda assim, lidar mal com novas tentativas ou pagamentos duplicados.

Por isso, um portefólio credível ou uma revisão interna deve incluir um conjunto de avaliação específico para a tarefa. O conjunto pode conter relatórios de erros representativos, percursos normais dos utilizadores, entradas malformadas, limites de permissões, falhas de dependências e regressões corrigidas anteriormente. Cada caso deve ter um resultado esperado explícito, e não apenas uma captura de ecrã que parece correta.

O pacote mínimo de testes para software criado por IA

Para uma aplicação pequena, é possível criar um pacote de qualidade útil sem um laboratório de investigação elaborado:

  • Testes de aceitação: verificam o comportamento visível para o utilizador nos fluxos de trabalho mais importantes, incluindo resultados bem-sucedidos e malsucedidos.
  • Testes unitários e de integração: verificam as regras de negócio isoladamente e confirmam que bases de dados, APIs, filas e autenticação funcionam em conjunto conforme pretendido.
  • Testes negativos: enviam entradas em falta, malformadas, demasiado grandes, duplicadas e não autorizadas. O código gerado por IA costuma parecer mais forte no caminho mostrado no prompt, por isso os caminhos não solicitados são importantes.
  • Testes de regressão: transformam cada defeito descoberto num teste permanente. Uma demonstração bem-sucedida depois de uma correção não é suficiente se a mesma falha puder regressar na alteração gerada seguinte.
  • Verificações de segurança: testam o controlo de acesso, o tratamento de segredos, as defesas contra injeção, as vulnerabilidades das dependências e se conteúdos não confiáveis podem influenciar chamadas de ferramentas ou ações privilegiadas.
  • Verificações operacionais: verificam tempos limite, novas tentativas, idempotência, registos, alertas e o comportamento seguro quando uma dependência está indisponível.

Isto está próximo da mentalidade de engenharia de QA descrita no relato do Stack Overflow sobre um ciclo de vida de desenvolvimento de software agentivo. A mudança importante é cultural: a garantia de qualidade não é uma inspeção final depois de uma IA ter escrito o código. É a estrutura que torna a geração rápida suficientemente segura para ser utilizada.

Teste a orquestração, não apenas o resultado

Quando o software inclui um agente de IA, os testes normais da aplicação são necessários, mas insuficientes. O sistema pode falhar porque o modelo interpretou mal um pedido, mas também pode falhar porque a orquestração envolvente perdeu contexto, chamou uma ferramenta duas vezes, aceitou uma saída estruturada malformada ou nunca terminou.

As áreas de regressão recomendadas pelo resumo antes da implementação são uma lista de verificação prática: perda de contexto, idempotência das ferramentas, injeção de prompt, saída estruturada, não terminação, fundamentação da recuperação e reidratação do estado. Estas são propriedades de engenharia testáveis.

Por exemplo, um teste pode executar o mesmo pedido duas vezes e confirmar que a segunda tentativa não cria uma encomenda duplicada. Outro pode interromper um agente a meio de um fluxo de trabalho, reiniciá-lo e verificar se ele retoma a partir de um estado válido em vez de repetir uma ação irreversível. Um teste de recuperação pode exigir que o sistema cite ou devolva apenas informações de um conjunto de fontes aprovado. Um teste de saída estruturada pode fornecer uma resposta inválida e confirmar que a aplicação a rejeita com segurança, em vez de a tratar silenciosamente como dados válidos.

Os sistemas de longa duração e multiagente precisam de registos de falhas especialmente claros. Os investigadores estão a trabalhar na atribuição automatizada de falhas, porque pode ser difícil identificar qual agente causou uma falha e em que ponto de uma longa cadeia de interação. Em termos práticos, as equipas devem preservar chamadas de ferramentas, entradas, saídas, versões dos modelos, marcas temporais, transições de estado e decisões finais num registo de auditoria que respeite a privacidade. Sem essas evidências, um teste vermelho diz que algo falhou, mas não indica por onde começar a corrigir.

A reprodutibilidade tornar-se-á uma vantagem profissional

O código gerado por IA é variável. Uma nova execução pode produzir uma implementação diferente; uma atualização do modelo pode alterar o comportamento; uma interrupção do fornecedor pode mudar o encaminhamento ou a latência. Por isso, os empregadores valorizarão os candidatos que consigam tornar as avaliações repetíveis.

Isso significa fixar instantâneos do modelo sempre que possível, registar prompts e configurações, controlar a aleatoriedade quando a plataforma o permitir e executar várias tentativas para tarefas cujos resultados variam. O resumo aponta especificamente para instantâneos fixados, temperatura baixa ou nula quando disponível e portas de controlo de CI/CD limitadas por confiança como salvaguardas úteis.

Um relatório prático deve distinguir pelo menos três resultados:

  1. Taxa de aprovação: quantos casos foram bem-sucedidos.
  2. Consistência: com que frequência o mesmo caso é bem-sucedido em execuções repetidas.
  3. Gravidade: se as falhas são meramente cosméticas, inconvenientes, causam danos aos dados, têm implicações de segurança ou podem provocar uma ação externa insegura.

Um sistema que passa em 19 de 20 verificações de formatação de baixo risco não é necessariamente melhor do que um que passa em 18 de 20 casos, mas nunca ultrapassa um limite de autorização. O padrão de qualidade deve ponderar as falhas de acordo com suas consequências.

A revisão humana deve visar o risco, não cada linha

O objetivo de uma automação melhor não é obrigar uma pessoa a reler cada token produzido por uma IA. É direcionar a atenção humana para as decisões que os testes não conseguem resolver completamente.

Os revisores devem se concentrar em autenticação e autorização, retenção de dados, ações financeiras ou contratuais, privacidade, migrações, recuperação de erros, permissões de terceiros e alterações que afetem o próprio mecanismo de avaliação do sistema. No caso de um agente, também devem revisar quais ferramentas ele pode chamar, a quais dados cada ferramenta pode ter acesso e se é necessária aprovação antes de uma ação irreversível.

Diferenças visíveis, fluxos de aprovação, conversas arquivadas e logs de auditoria — recursos destacados na descrição do Slack Code sobre programação colaborativa com IA — apontam para uma expectativa mais ampla: o histórico de como o software foi criado será importante. Um revisor deve conseguir entender a solicitação, inspecionar a alteração gerada, ver as evidências dos testes e identificar quem aprovou a implantação.

Esse registro não é burocracia por si só. Ele permite distinguir uma demonstração impressionante de uma alteração controlada que outra pessoa possa manter.

O que incluir em um portfólio ou entrevista

Para candidatos, a demonstração mais forte é um sistema pequeno com uma história de qualidade deliberadamente visível. Inclua o repositório, instruções de configuração, notas sobre a arquitetura, comandos de teste, casos de teste representativos, limitações conhecidas e um breve relatório de falhas. Mostre um ou dois bugs que foram encontrados e transformados em testes de regressão. Explique qual modelo ou agente de programação foi usado sem apresentar a ferramenta como autora das decisões de engenharia.

Se a aplicação usa um agente, documente as permissões das ferramentas, o modelo de estado, a política de novas tentativas, a condição de término e os pontos de aprovação humana. Se usa recuperação de informações, mostre como as fontes são selecionadas e o que acontece quando faltam evidências. Se chama serviços externos, demonstre o comportamento diante de timeouts e solicitações duplicadas.

Não alegue confiabilidade com base em uma única gravação bem-sucedida. Uma afirmação verificável seria mais ou menos assim: “Em 30 execuções registradas desses 12 cenários, o sistema atendeu aos critérios de aceitação em 28; as duas falhas envolveram uma entrada de data ambígua, e ambas estão documentadas.” O número em si é menos importante do que o método, os limites e a honestidade sobre o que ainda não foi testado.

A nova definição de rapidez

A IA reduz o custo de produzir uma primeira versão. Ela não elimina o custo de saber se essa versão merece confiança. Na verdade, uma geração mais rápida pode tornar a avaliação ainda mais importante, pois mais alterações não revisadas podem se acumular entre as implantações.

O profissional da era pós-programação por vibração será avaliado pelo ciclo: definir o comportamento, gerar ou modificar o código, testar casos realistas e adversariais, inspecionar decisões de alto risco, registrar falhas e melhorar o sistema sem perder as evidências. Benchmarks podem ajudar a comparar a capacidade. As práticas de QA determinam se essa capacidade se transforma em software confiável.

O padrão de qualidade, portanto, não é “Você consegue criar um aplicativo com IA?”. É “Você consegue provar o que o aplicativo faz, detectar quando ele deixa de fazê-lo e projetar os limites que impedem que uma falha se transforme em um incidente?”.