HITL em Vibe Coding e IaC: Evite a Conta Longa

A IA generativa já escreve specs, código e pipelines completos. Remover o humano do processo não te dá velocidade: te dá tokens queimados, drift em produção e noites de oncall que você poderia ter evitado com um único checkpoint bem colocado.

Em 2026, o discurso corporativo vai quase tudo em uma única direção: agentes autônomos, full automation, self-healing pipelines. A promessa é sedutora porque vende. A realidade operacional é que quase nenhum equipe está pronta para executar essa promessa sem um humano validando os pontos críticos do fluxo.

Já escrevi antes sobre a falsa promessa da autonomia comprada. Aquele post diagnosticava o problema. Esta é a versão prescritiva: onde colocar o HITL (Human In The Loop), o que validar em cada gate e por que pular essa disciplina se paga em tokens, em MTTR e em horas de retrabalho.

HITL não é freio, é multiplicador

Há uma confusão muito enraizada em equipes que estão explorando fluxos agênticos: pensar que HITL significa “o humano revisa tudo” ou “o humano freia a IA”. Nenhuma das duas coisas escala.

HITL bem projetado funciona como um gate em transições críticas de estado. A IA sugere, propõe, otimiza, detecta erros de digitação que o olho humano deixa passar. O humano aprova a passagem de uma etapa para a seguinte quando essa etapa é custosa de reverter. É a mesma lógica que aplicamos em CI/CD há anos: você não bloqueia cada commit, bloqueia o merge para main e o deploy em produção.

Aplicado a fluxos com IA, os dois lugares onde o gate paga seu custo com juros são a definição de specs em Vibe Coding e o caminho de IaC para produção.

HITL em Vibe Coding: o gate está no SDD, não no código

Quando um agente entrega um Pull Request medíocre, o reflexo natural é revisar o código linha por linha. É tarde. O erro quase nunca está no código; está na spec ou prompt que gerou esse código.

Spec Driven Development (SDD) dá estrutura ao agente: requirements (Requisitos), scenarios (Cenários), design decisions (Decisões de Design), tasks (Tarefas). Sem essa estrutura, o agente alucina interfaces, inventa contratos e mistura domínios. Com essa estrutura, o agente avança com menos ruído e mais previsibilidade.

O problema é que uma spec mal definida é radioativa. O agente vai interpretá-la literalmente e vai gerar 800 linhas de código que cumprem à risca algo que não era o que você queria. Depois vêm as correções, os re-prompts, os rollbacks parciais. Cada iteração consome o contexto completo do repo, specs intermediárias e o histórico da conversa.

Uma estimativa conservadora baseada em projetos reais: uma feature média iniciada com uma spec fraca geralmente requer entre 3 e 5 iterações extras de correção, cada uma consumindo entre 30k e 80k tokens. Isso é entre 100k e 400k tokens queimados que não agregaram valor, apenas desfizeram uma decisão que foi tomada errada no início.

O HITL em SDD é barato comparado com isso. Dez minutos revisando se a spec descreve o problema correto, se os cenários cobrem os edge cases conhecidos e se as decisões refletem o stack real do projeto. Esse gate evita que o agente gere metade do sistema sobre uma premissa equivocada.

Frameworks SDD não são mágica

Aqui há um ponto que está sendo ignorado em muitas equipes: adotar um framework SDD como OpenSpec ou SpecKit não resolve o problema apenas por instalá-lo. O framework te dá o esqueleto: estrutura de pastas, tipos de artefatos, fluxo de execução, hooks. O que ele não te dá é contexto do domínio, regras da sua organização nem convenções do seu stack.

Se você deixar o framework na configuração padrão, o agente continua alucinando. Não alucina menos por usar OpenSpec; alucina diferente. Vai inventar bibliotecas, vai sugerir padrões de microserviços onde seu projeto é um monolito modular, vai propor arquiteturas event-driven quando sua equipe de cinco pessoas não as opera bem.

Personalizar o framework é trabalho de engenharia: glossário de domínio injetado no contexto, regras de codificação do projeto, restrições do stack (versões de runtime, bancos de dados permitidos, libraries vetadas), naming conventions, critérios de testing. Essa camada é o que transforma um framework genérico em algo que reduz alucinações de verdade.

O HITL convive com tudo isso. O humano valida que o framework está bem configurado, que as regras se mantêm atualizadas e que cada spec gerada respeita essas regras antes que o agente desça para implementação. Sem essa validação, o framework apenas dá aparência de rigor a um fluxo que continua caótico.

HITL em IaC e GitOps: o gate vai antes do apply, não depois

Em infraestrutura, a tentação de deixar a IA executar por CLI direto é alta. Há agentes que podem rodar terraform plan, terraform apply, kubectl apply, gh workflow run. Funcionam. O problema é que o custo de um erro em infra não se mede em re-prompts, se mede em outages.

Um caso real que se repete: um agente gera uma mudança no Terraform onde um for_each recebe um mapa com keys diferentes das do state. Para o olho humano sem contexto suficiente, o diff parece razoável. O plan mostra “5 to add, 5 to destroy”. Se ninguém revisa esse plan com critério, o apply apaga cinco recursos produtivos e os recria com IDs novos. Endpoints quebrados, downtime medido em minutos no melhor caso e em horas se depende de DNS ou de coisas que se replicam lentamente.

O HITL em IaC não significa que um humano aprove cada terraform apply. Isso gera muita fricção e termina em rubber stamping, que é pior do que não ter gate. O HITL útil está em dois pontos específicos:

Pull Request review antes do merge, com o plan anexado no PR (estilo Atlantis, Terraform Cloud ou Argo CD com preview). O humano lê o plan e aprova a mudança quando entende o que será tocado.
Promotion gate entre ambientes (staging → prod), onde um humano confirma que o aplicado em staging se comportou como esperado antes de propagar para prod.

O que a IA contribui nesse fluxo é valioso e específico: detecta erros de digitação, valida que o código compile, sugere otimizações de módulos, compara o diff contra o state, anota riscos potenciais no PR. É trabalho que um humano faz devagar e mal porque é repetitivo. A IA faz rápido e consistente.

Uma estimativa baseada em equipes que adotaram esse modelo: gating o merge e a promotion com HITL reduz incidentes graves atribuíveis a mudanças de infra entre 30 e 50%. Não elimina os incidentes, mas os empurra para categorias menos custosas e deixa o MTTR muito mais saudável porque o rollback é decidido com contexto, não em pânico.

Checklist de gates: onde colocar o humano

Resumo acionável, pensado para equipes que estão montando seu fluxo com agentes:

Gate 1, Spec aprovada: antes que o agente gere uma única linha de código, um humano valida que a spec descreve o problema correto, os cenários cobrem os edge cases conhecidos e as decisões refletem o stack real.
Gate 2, Framework SDD configurado: revisar periodicamente que as regras, glossários e restrições do framework estejam atualizados com a evolução do projeto. Frameworks não se auto-administram.
Gate 3, PR review com plan visível: em IaC, nenhum merge para main sem que o terraform plan (ou equivalente) esteja no PR (pipeline executado) e tenha sido lido por um humano que entenda quais recursos toca.
Gate 4, Promotion entre ambientes: a etapa de staging para prod requer confirmação humana, idealmente com métricas de staging anexas. Apply automático em prod sem validação prévia de staging é dívida técnica disfarçada de velocidade.
Gate 5, Auditoria de output do agente: spot-check periódico dos PRs aprovados por agentes para detectar drift em qualidade antes que se torne sistêmico.

Conclusão

A conversa interessante em 2026 já não é se usar IA no ciclo de desenvolvimento, mas onde deixá-la decidir sozinha e onde forçar um humano no meio. As equipes que estão tirando ROI real entenderam: HITL não é resistência à mudança, é disciplina de engenharia aplicada ao novo stack.

Pular essa disciplina por entusiasmo ou por pressão de um roadmap agressivo é barato no início e caro no final. A conta chega na forma de tokens consumidos, incidentes de produção e confiança corroída com o negócio. Colocar os gates corretos custa menos do que qualquer uma dessas três coisas.

A IA é um multiplicador brutal quando opera dentro de um quadro que definimos para ela. Sem esse quadro, o multiplicador funciona igualmente bem para o caos.