O código virou assembly? Reflexões sobre code review, QA e uma PoC de 32 mil linhas de shellscript

Esses dias caí numa discussão num grupo de desenvolvedores que ficou martelando na minha cabeça por dias. Resolvi sentar e escrever para organizar o que estou pensando — e, principalmente, o que estou vendo acontecer no meu trabalho.

Bora lá.

A provocação foi mais ou menos assim: alguém defendeu que linguagens de programação se tornaram baixo nível, como assembly. Ninguém mais revisa o código que o compilador gera, certo? Então por que ainda revisaríamos código gerado por LLM? O futuro, segundo essa visão, talvez não seja exatamente o que o Uncle Bob projeta hoje — mas a direção parece clara: nos afastamos da sintaxe.

Outro colega devolveu uma reflexão que achei boa: se vamos rodar o código localmente, debugar para verificar comportamento, escrever testes de aceitação como o próprio Uncle Bob defende em Clean Architecture… então, no fim das contas, viramos QAs. Vamos desenvolver todo tipo de teste possível ao redor do software para garantir que ele se comporta como deveria.

Cara, essa pergunta me pegou. Porque é exatamente o trabalho que faço.

Minha pergunta real: como revisar 2.000 a 4.000 linhas geradas?

Trabalho com automação de testes há alguns anos. SDET, QA Engineer — o nome muda, o trabalho é o mesmo: garantir que o que foi combinado é o que foi entregue.

Uso IA no fluxo desde 2024. Não como brinquedo, como ferramenta diária — apoio na escrita de testes automatizados, planejamento de testes, geração de documentação, levantamento de cenários. É parte do meu setup, do mesmo jeito que IDE, terminal e pipeline são. Quem trabalha comigo sabe que defendo isso há tempo: IA deixou de ser experimento para virar régua.

Mesmo com essa prática diária, uma parede continua difícil de furar: como faço code review eficiente em 2k, 3k, 4k linhas escritas de uma só vez?

Três perguntas ficaram aqui no terminal comigo:

Como manter revisão humana minimamente honesta diante de volumes que ninguém lê linha a linha?
Vai chegar um momento em que, se o que foi testado está conforme o combinado, a revisão humana de código deixa de ser relevante?
Arquiteturas que nasceram para facilitar o cognitivo humano — Hexagonal, Clean Architecture — continuam relevantes no contexto de agentes que não têm “carga cognitiva” no sentido humano?

Nenhuma dessas perguntas eu respondo com confiança hoje. Algumas, estou tentando responder na prática.

A PoC honesta: 32 mil linhas de shellscript

Para falar com honestidade desse assunto, preciso colocar skin in the game — empresto o termo do Taleb porque acho ele exato: só falo do que vivi.

Entre os vários experimentos que rodei nesse último ano e meio com IA no trabalho, um se destacou. Recebi a missão de mexer numa automação de testes escrita em shellscript. Mais de 32 mil linhas. Complexidade ciclomática alta. Manutenibilidade baixa. O tipo de codebase em que abrir um arquivo já consome um café inteiro só para entender o que ele faz.

Foi uma das PoCs que mais deu certo no meu fluxo até agora.

Aprendi algumas coisas que valem registrar:

Sem testes, agente nenhum salva você. Boa parte do tempo da PoC foi gasto criando rede de segurança antes de qualquer refatoração assistida. É o trabalho clássico do QA — e ele virou pré-requisito do uso eficiente de IA, não substituto.
Funções pequenas e responsabilidade única continuam de pé. Quando o agente gera código que respeita esses princípios, eu consigo revisar. Quando gera blocos monolíticos, eu mando refazer. Não é detalhe técnico — é o que torna o resultado revisável.
A revisão muda de natureza, não desaparece. Ao invés de caçar bug em loop com for, passei a revisar intenção. O código faz o que o teste descreveu? Cobre os casos de borda que combinei? A arquitetura permanece coerente?
Decompor o problema antes do prompt importa mais que o prompt. Pedir “refatore esse arquivo de 4k linhas” raramente funciona. Pedir “extraia a função X, com responsabilidade Y, validando entrada Z” funciona quase sempre.

Não vou romantizar. Há trechos em que joguei a saída do agente fora porque ficou pior que o original. Há outros em que o ganho foi real e me poupou horas. É um começo de método — não um ponto final.

Esse é um caso entre vários. Uso IA também para acelerar planejamento de testes (transformar regra de negócio em matriz de cenários), para documentar suítes legadas que ninguém mais lembra como funcionam, e para gerar primeiras versões de cenários BDD a partir de critério de aceite. Cada frente tem sua armadilha. Mas todas elas dependem da mesma disciplina antiga: saber o que você quer antes de pedir.

O que o Fowler chama disso

Recentemente, no site do Martin Fowler, Wei Zhang e Jessie Jie Xia (ambos da Thoughtworks) publicaram um artigo chamado Structured Prompt-Driven Development (SPDD). Vale a leitura.

A ideia central, em uma frase: trate seus prompts como artefatos versionados e governados, não como descartáveis de chat. Ela propõe um canvas (REASONS — Requirements, Entities, Approach, Structure, Operations, Norms, Safeguards) para estruturar a intenção antes de gerar código, e defende um loop bidirecional entre especificação e código quando algum dos dois muda.

Duas ideias que sublinhei:

A velocidade local melhora, mas isso não se traduz automaticamente em throughput no nível do sistema.
O code review passa de “ache o bug” para “verifique a intenção”.

Foi exatamente o que senti na PoC.

O que continua sendo nosso trabalho

Volto à pergunta do colega: viramos QAs?

Acho que parte de nós sempre foi. A diferença é que agora o resto da indústria vai precisar aprender o que QAs já sabiam: que o código é a parte fácil; o difícil é garantir que o código faz o combinado, em produção, sob carga, com gente real do outro lado.

Aposto algumas fichas no que vai voltar com força:

Clean Code minimalista. Funções pequenas, responsabilidade única, testabilidade. Não como dogma, mas como contrato com o agente. Código limpo é código revisável — e revisável é o que sobrevive.
XP, redescoberto. Estou voltando a estudar Extreme Programming. Faz sentido demais agora: integração contínua de verdade, testes em primeiro lugar, refatoração constante, propriedade coletiva do código. Anotem.
Pair Programming, ressignificado. O par muda — às vezes é humano, às vezes é o agente, ideal é os três juntos. O ritual é o mesmo: alguém dirige, alguém revisa, ninguém aceita o que não entende.

Por fim

Não sei se a Hexagonal e a Clean Architecture continuam relevantes exatamente do jeito que aprendemos. Talvez se tornem padrões internos do agente, abstrações que ele segue sem precisarmos enxergar. Mas os princípios subjacentes — separar domínio de infraestrutura, testar por fora, garantir reversibilidade — parecem antifrágeis. Esses não vão a lugar nenhum.

A pergunta que me sobra, e que devolvo aqui: se a revisão humana for, daqui a algum tempo, mais sobre intenção do que sobre sintaxe — quem está se preparando hoje para revisar intenção?

Eu estou tentando. Aos tropeços, com 32 mil linhas de shellscript de testemunha.

Se você está nesse mesmo lugar, me chama. Pair programming continua valendo.