A IA pode escrever o código. Alguém ainda precisa cuidar da qualidade.

A velocidade parece real. A bagunça aparece depois.

Um dono de pequeno negócio pede uma mudança no agendamento na segunda-feira. À tarde, uma tela que funciona já está na demonstração. Um fundador técnico costumava levar dias nesse tipo de funcionalidade. Um agente de código rascunhou isso antes do almoço.

A velocidade é real. A ideia difícil é mais simples do que as ferramentas ao redor: código mais rápido não é o mesmo que um fluxo de trabalho que você consegue repetir sem quebrar a qualidade para o cliente. Uma funcionalidade que aparece rápido ainda pode ser cara de mudar, difícil de explicar e arriscada de deixar na frente de clientes que pagam.

Esta lição parte da palestra de Dexter Horthy, Fighting Code Slop: The State of Software Factories. Ele fala com quem entrega software com agentes. A mesma lição importa se você compra software e ajuda de IA e nunca abre um editor de código.

Isto é para donos que contratam desenvolvedores ou fornecedores, e para fundadores que entregam com agentes de código. Você não precisa de um time grande de engenharia para sentir o custo de um software bagunçado. Você precisa de clientes que percebem quando algo quebra.

O que uma fábrica de software realmente é

Uma fábrica de software não é um prédio nem um produto novo de IA. É o caminho de “devemos construir isso” até “um cliente está usando”. Esse caminho inclui o pedido, a construção, as checagens, a entrega e o retorno que chega depois que as pessoas experimentam.

Horthy trata a fábrica como um padrão antigo de engenharia, não como uma invenção da IA. Na palestra, uma fábrica de 2022 é a linha de base: as pessoas já tinham um ciclo para transformar trabalho em software antes de os agentes conseguirem rascunhar a maior parte do código.

Na linguagem do dono, o ciclo fica assim. Alguém nomeia um trabalho. Alguém constrói. Alguém confere. Você entrega. Os clientes reclamam, pedem a próxima coisa ou ficam quietos de um jeito que ainda ensina algo. Esse próximo trabalho volta para a lista.

Monitoramento e correções de madrugada entram nesse ciclo. Fazem parte da qualidade, não de um hobby técnico à parte. Se uma mudança ruim chega ao cliente e ninguém consegue ver, reverter ou explicar, a fábrica está incompleta. O software pode parecer pronto. O negócio continua exposto.

O que os agentes mudam, e o que não mudam

O que mudou é quanto da construção um modelo consegue fazer. Em tarefas menores, um agente pode pegar um ticket e produzir algo perto de um pull request: uma mudança proposta que uma pessoa pode revisar. Isso é útil. Não é a fábrica inteira.

A tese, em palavras simples, é esta: deixar modelos sem supervisão não vai, por si só, melhorar nem manter a qualidade de uma base de código ao longo do tempo. Os modelos ficaram muito melhores em resolver um problema enunciado. Essa é uma habilidade diferente de escolher a estrutura, as peças compartilhadas e um lugar claro para uma regra viver.

Resolver rápido significa que a tela de agendamento funciona na demonstração. Escolher a estrutura significa que a regra “um horário cancelado libera a vaga” vive em um só lugar, com um nome que um humano encontra no mês seguinte. Se essa regra for copiada em três arquivos, a próxima mudança corrige uma cópia e deixa as outras para trás.

Nomeie o tradeoff antes de falar de ferramentas. Minutos economizados hoje podem virar meses de confusão se o software ficar mais difícil de mudar. A tarde barata não é barata se cada correção depois exigir uma semana de arqueologia.

Por que “funciona” é uma checagem fraca de qualidade

Manutenibilidade não tem um oráculo rápido. Uma funcionalidade pode passar na demonstração, agradar quem pediu e ainda ser cara de corrigir no mês seguinte. “Funciona” responde à pergunta de hoje. Não responde se a próxima pessoa, ou o próximo agente, consegue mudar isso sem quebrar a qualidade para o cliente.

Horthy aponta o SlopCodeBench como um jeito de olhar esse tipo de qualidade, não só se o código roda. Trate isso como a afirmação do palestrante, não como um estudo que este texto está reapresentando. Ele argumenta que até modelos fortes pontuaram mal na qualidade que esse bench tenta medir. Se você quiser a nota exata e o método, assista à palestra e leia as fontes que ele cita lá. Este texto não vai inventar um resultado mais completo.

Para um dono não técnico, “code slop” não é um insulto ao seu desenvolvedor. É lógica duplicada, nomes pouco claros e mudanças que ninguém consegue explicar quando um cliente relata um problema. A tela funciona até um reembolso, um fuso horário ou uma segunda unidade expor a cópia que nunca foi atualizada.

Essa bagunça atinge o lucro. Retrabalho, incidentes e correções lentas consomem o tempo que a IA deveria liberar. Um fluxo de trabalho prático só economiza tempo se a checagem for real. Se cada hora economizada volta como emergência, o software não fica mais lucrativo. Só fica mais rápido em criar trabalho que você não planejou.

Práticas que mantêm um humano no ciclo

Planeje antes de construir, mas não planeje demais. Diga a quem a mudança serve, como é o pronto e onde isso deve viver no software. Um plano curto basta: “Clientes recorrentes podem remarcar pelo link do lembrete. Pronto significa que a vaga antiga está livre e o cliente vê o novo horário. A regra vive com os agendamentos, não no modelo de e-mail.” Um spec do tamanho de um romance não é necessário. Um “pronto” ausente é como o slop ganha número de ticket.

Alinhe visualmente antes de uma mudança grande. A ideia de “me mostra”, do Horthy, combina bem com donos. Um esboço, uma tela ou um passo a passo curto vale mais do que uma pilha de arquivos gerados. Se você não consegue apontar a tela e dizer o que deve acontecer, não peça a um agente para inventar o resto.

Traga o retorno real do usuário para o fluxo de trabalho. Reclamações e pedidos de funcionalidade não são ruído depois do lançamento. São os próximos trabalhos da lista. Feature flags ajudam aqui: um modelo pode testar uma mudança com um grupo pequeno, ou na sua própria conta, sem expor todos os clientes de uma vez. A flag é uma ferramenta de qualidade, não um truque. Você ainda precisa de uma pessoa que decida quando é seguro abrir.

Trate os ciclos como pressão para a frente mais pressão de volta. Agentes podem rascunhar. Revisão, testes e uma pessoa que pode rejeitar o trabalho ficam no caminho. Pressão para a frente é a vontade de entregar. Pressão de volta é o direito de dizer não, pedir um nome mais claro ou devolver a mudança porque a regra agora vive em dois lugares.

Guarde as lições das sessões anteriores para a próxima execução não repetir a mesma escolha bagunçada. Se o bug do mês passado veio de uma regra de reembolso copiada, escreva isso onde o próximo agente e o próximo humano vão ver. Memória faz parte da fábrica. Um chat novo, sem histórico, redescobre seus erros antigos em velocidade máxima.

Um próximo passo pequeno para donos e fundadores

Não compre outra ferramenta de agente até conseguir nomear uma tarefa repetida e a checagem de qualidade que um humano ainda vai fazer. Se você não consegue nomear a tarefa, a ferramenta é um palpite. Se você não consegue nomear a checagem, automatizou o rascunho e abandonou a fábrica.

Se você é um fundador técnico, escolha uma mudança que está por vir. Escreva o plano em linguagem simples: a quem serve, como é o pronto e onde a regra deve viver. Depois leia o diff antes de entregar. Não aprove uma mudança que você não consegue explicar a um cliente que está travado.

Se você tem um negócio local de serviço, faça três perguntas ao seu desenvolvedor ou fornecedor. Onde a IA está escrevendo código? Quem revisa? Como uma mudança ruim é revertida? Você não está pedindo para pararem de usar IA. Está perguntando quem cuida da qualidade quando a demonstração da tarde vira a página de agendamento de amanhã.

A IA pode acelerar a fábrica. Clareza, revisão e qualidade para o cliente são o que a mantêm lucrativa. O próximo passo pequeno é nomear a tarefa, nomear a checagem humana e manter esse par no fluxo de trabalho antes de adicionar outra ferramenta.