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

> O que continua sendo trabalho de QA quando o agente escreve milhares de linhas? Notas de uma PoC de refatoração com IA em 32 mil linhas de shellscript.

- URL: https://iagofrota.com.br/blog/code-review-qa-e-uma-poc-de-32-mil-linhas-de-shellscript/
- Data: 2026-05-08
- Tags: code-review, qa, ia, automacao-de-testes, clean-code, xp, pair-programming, shellscript, skin-in-the-game

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:

1. Como manter revisão humana minimamente honesta diante de volumes que ninguém lê linha a linha?
2. 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?
3. 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.