Humano no loop com a IA?

Passei os últimos anos construindo software com auxílio de IA. E fui percebendo que o meu problema quase nunca era se o código gerado funcionava, pois os testes passavam e o sistema se comportava como esperado. O problema era outro: eu já não conseguia explicar por que certas decisões de arquitetura tinham sido tomadas. Acompanhar a evolução da base de código consumia um tempo enorme e me deixava com uma pergunta incômoda: eu tinha revisado tudo o que deveria?

Tentei o caminho de usar linters e outras IAs treinadas como revisoras, pedindo que avaliassem se o código aderia à especificação. Por um tempo, deu uma sensação de controle. Mas frequentemente durante o desenvolvimento, eu encontrava situações de melhoria real do sistema, como separações de responsabilidades que estavam se acumulando em determinadas etapas, padronização de rota de normalização compartilhadas por diferentes fluxos, separação de regras reutilizadas em diferentes pontos da pipeline, etc. Me vi na situação onde a codebase evolui para uma arquitetura que não estava prevista na spec inicial e que decisões importantes sobre a intenção do sistema podiam ser registradas tanto nas specs (e deveriam ser mantidas) quanto na codebase (e deveriam sobreviver à comparação com as specs).

Para mim está claro que decisões fundamentais de desenvolvimento devem ser tomadas por seres humanos. A expressão “human in the loop” aparece cada vez mais nas discussões sobre desenvolvimento assistido por IA, registrando que pessoas devem ocupar uma posição no workflow de desenvolvimento junto das IAs. Mas estar no loop não é uma atividade. Se alguém recebe centenas de decisões técnicas e as aprova na velocidade em que elas chegam, temos presença humana sem autoridade humana real. O revisor vira mais um componente do pipeline, não o responsável pela decisão. Isso não é supervisão. É carimbo! E o pior: o registro que sobra pode ser pior do que registro nenhum, porque a aprovação sobrevive e depois é lida como se tivesse refletido uma decisão ponderada.

A produção acelerou dramaticamente com a IA. A nossa capacidade de verificar, julgar e registrar não acompanhou. Então a pergunta que me parece útil não é “como fazer humanos revisarem mais rápido”. É outra: Em que granularidade o julgamento humano deve ser exigido — e que evidência cada pedido de julgamento precisa carregar para sustentar uma decisão responsável?

Minha aposta é que a resposta à assimetria de velocidade nunca será exigir que humanos processem na velocidade da máquina. É colocar, entre a produção e o julgamento, uma camada determinística de verificação capaz de reduzir, priorizar e estruturar o que de fato precisa chegar a uma pessoa — deixando o resto operar em escala de máquina, mas mantendo o julgamento humano obrigatório nos pontos onde removê-lo significaria delegar uma decisão que não deveria ser delegada.

Escrevi um ensaio desenvolvendo esse argumento, publicado semana passada no BLOG@CACM (Communications of the ACM):
https://cacm.acm.org/blogcacm/human-control-at-machine-speed/

Mas a pergunta me interessa para quem está usando IA para produzir código no dia a dia: onde vocês traçam essa linha? O que, na prática de vocês, TEM que passar por um humano? E o que já não passa mais?