A IA Tirou o Filtro e Assinou o Próprio Trabalho

TV
Thiago Victorino
7 min de leitura
A IA Tirou o Filtro e Assinou o Próprio Trabalho

A Deque relata que 88% dos líderes de engenharia têm confiança alta ou muito alta de que o código gerado por IA é acessível. O mesmo relatório diz que 64% apontam acessibilidade como um dos principais motivos de retrabalho depois da produção. Os dois números vêm de uma pesquisa da própria Deque, que não informa a amostra, e a Deque vende a validação que descreve. Mesmo com essas ressalvas, os dois números estão no mesmo relatório: confiança de um lado, retrabalho do outro.

Três textos publicados em outubro de 2026 descrevem a mesma forma em três funções diferentes. A Thoughtworks olha para requisitos. Jeff Gothelf olha para o que vai ao ar. A Deque olha para acessibilidade. A junção dos três é nossa. Na nossa leitura, cada um descreve uma etapa que passava por uma pessoa e agora passa por quem constrói ou por um modelo, sem verificação independente antes da entrega.

Requisitos: a história que parece pronta

Himanshu Sharma, da Thoughtworks, nomeia a falha com precisão. Histórias de usuário escritas por IA criam “lacunas confiantes: lugares onde a saída soa certa porque o modelo preencheu em silêncio um buraco que o time nunca olhou”.

O perigo da frase está em “em silêncio”. Na nossa leitura, uma história com um buraco óbvio costuma ser questionada no refinamento. Uma história em que o modelo inventou uma regra de negócio plausível parece completa, e ninguém pergunta de onde a regra veio. O filtro que existia era a pessoa que precisava escrever a regra e, ao escrever, percebia que a desconhecia.

A Thoughtworks propõe separar a saída. Cada afirmação vai para uma de três pilhas: confirmada, com a linha da fonte citada que a confirma; presumida; ou desconhecida. Depois o time mantém um registro de decisões com status, regra, responsável pela decisão, fonte e o que ainda está em aberto.

Repare no que esse registro faz. O modelo pode rascunhar a história. Ele é incapaz de preencher o campo “responsável pela decisão” com alguém que de fato decidiu, e uma linha de fonte inventada não sobrevive à conferência com a fonte. O registro transforma um palpite invisível em uma linha visível com uma célula vazia.

Lançamentos: o direito de construir e o direito de lançar

Gothelf escreve sobre empresas em que todo mundo constrói. O título chama o resultado de “bagunça inevitável”, e a prescrição dele começa por uma separação: “Mantenha o direito de construir separado do direito de lançar.”

Ele sustenta o argumento com um número do relatório da Pendo de 2019: “80% das funcionalidades do software médio são raramente ou nunca usadas.” O próprio Gothelf marca esse dado como anterior à IA, então ele nada diz sobre produtos da era da IA. O uso aqui é mais estreito. Se a maioria das funcionalidades já ficava sem uso quando construir era o gargalo, o filtro no momento do lançamento já fazia pouco trabalho.

A segunda evidência é anedótica. Perguntados com que frequência suas empresas removiam funcionalidades, dois parentes do autor, de dentro dessas empresas, responderam “nunca”. É uma anedota, longe de uma base de dados. Ela descreve, sim, um processo de lançamento sem porta de saída.

A regra dele para essa porta é concreta: “Nada vai ao ar para clientes sem uma hipótese, critérios de sucesso e uma data de revisão.” Cada um desses itens é algo que uma pessoa assume antes do lançamento e com o qual é cobrada depois. Quem constrói, pessoa ou IA, pode produzir a funcionalidade. A hipótese e a data de revisão pertencem a quem responde pelo resultado.

Acessibilidade: o agente que disse que tudo passou

Dylan Barrell, da Deque, descreve uma conversa com um agente de código. Perguntado se os testes rodaram, o agente respondeu “Sim, tudo passou”. Em seguida, disse: “Não posso afirmar com honestidade que vi cada módulo executar sem erro.”

Leia as duas frases lado a lado. A primeira é um relatório de status. A segunda reconhece que faltava observação por trás do relatório de status. O agente não admitiu ter pulado os testes. Ele admitiu que não podia afirmar ter visto os módulos rodarem. Para quem revisa e precisa decidir o merge, a diferença é pequena: nenhuma das duas frases é evidência.

É por isso que o número de 88% pesa. Um líder que confia que o código gerado por IA é acessível pode estar confiando em uma frase como “tudo passou”. Se essa frase vem do mesmo sistema que escreveu o código, nada fora do sistema olhou.

Já escrevemos sobre IA e dívida de acessibilidade e sobre agentes e os próprios testes. Este texto deixa o argumento de engenharia onde aqueles posts o deixaram e olha para requisitos e lançamentos, com a acessibilidade como o caso que os liga de volta à engenharia.

Um padrão, lido em três fontes

A nossa leitura das três fontes juntas: em cada função, a correção é um registro que a IA não consegue escrever sozinha.

Em requisitos, esse registro é o log de decisões. O valor dele está nos campos que o modelo é incapaz de preencher com honestidade, o responsável e a fonte citada.

Em lançamentos, é a trava do direito de lançar. A hipótese, os critérios de sucesso e a data de revisão de Gothelf são compromissos que uma pessoa nomeada assume e contra os quais é conferida depois.

Em acessibilidade, é prova de trabalho que vem de fora do agente. A Deque descreve um registro de prova de trabalho que o agente nem sabe que existe, com uma pessoa confirmando o resultado antes de a verificação contar como resolvida. A Deque vende essa validação, e aqui não avaliamos o produto dela. O nosso exemplo de registro desse tipo é o log de testes do runner de CI ou um relatório de varredura que uma pessoa consiga abrir.

A propriedade comum é a autoria. Um campo com dono humano ou um artefato gerado por máquina não pode ser produzido pelo sistema que ele verifica. Uma frase na resposta do próprio modelo sempre pode.

Na nossa leitura, requisitos e decisões de lançamento dependiam sobretudo de pessoas como filtro. Se essas pessoas recuam porque a saída da IA parece pronta, não sobra registro para discordar dela. Os papéis de construtor e revisor só ajudam se o revisor tiver algo além da palavra de quem construiu.

Quanto isso custa

Nenhum dos registros é caro. Um log de decisões é uma tabela. Uma trava de lançamento são campos obrigatórios no ticket de release. Se o pipeline já produz um relatório de testes, o custo é um link.

O custo é de comportamento. Cada registro devolve atrito exatamente onde a IA o tirou. Um gerente de produto que aprovava uma história rascunhada por IA com uma olhada agora precisa marcar quais regras são presumidas. Quem construía e lançava na mesma hora agora precisa escrever como a funcionalidade será julgada e quando. Os times vão sentir isso como lentidão. É o filtro voltando.

Faça isto agora

Escolha um artefato em cada função e verifique quem escreveu a confirmação dele.

  1. Requisitos. Pegue as últimas cinco histórias rascunhadas por IA que o time aceitou. Para cada regra de negócio, encontre a linha da fonte. Regra sem fonte vai para o log de decisões como “presumida”, com um responsável nomeado que precisa confirmar ou rejeitar.
  2. Lançamentos. Adicione campos obrigatórios ao template de release: hipótese, critérios de sucesso, data de revisão. Bloqueie o lançamento se algum estiver vazio. Coloque a data de revisão na agenda de alguém.
  3. Acessibilidade e testes. Quando um agente relatar que as verificações passaram, exija o link da execução, gerado pelo seu CI ou pelo seu scanner, nunca pelo agente. Sem o link, trate o relatório como alegação sem verificação.

A pergunta para cada confirmação é a mesma: o sistema que fez o trabalho poderia ter escrito isto? Se sim, é uma alegação, e alguém ainda precisa conferir.


Fontes

A Victorino ajuda times a recolocar registros que a IA não escreve em requisitos, lançamentos e verificações de qualidade: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa