O Despertar Incômodo

Recentemente me deparei com um post no LinkedIn de Rodrigo Morteo que tocou num ponto sensível. Após 20+ anos em desenvolvimento de software e automação de QA, ele confessa que as ferramentas de IA estão fazendo-o sentir-se desconfortável sobre nossa luta diária com requisitos.

Eu sou uma pessoa de Desenvolvimento de Software / QA Automation (agora SDET) há mais de 20 anos, e tenho uma confissão:

As ferramentas de codificação com IA estão me fazendo sentir “inquieto” sobre nossa luta eterna com requisitos 😬

Deixe-me explicar:

Por décadas, obter requisitos claros do “negócio” tem parecido arqueologia (cavando em busca da intenção), tradução (transformando vibes em especificações), e às vezes (talvez mais do que eu gostaria de admitir)… até mesmo como terapia 😅

Agora, entramos na era da “vibe-coding”, e de repente a tendência é alimentar a IA com:

• documentos de arquitetura bem elaborados
• documentos de planejamento detalhados
• user stories limpos com critérios de aceitação detalhados
• casos extremos + restrições

…e eu estou aqui tipo: ESPERA, você quer dizer que o negócio poderia ter nos dado isso (times de dev) o tempo todo? 🤔

Se tivéssemos tratado humanos da forma como estamos tratando os prompts de IA “intenção clara, restrições, exemplos”, a entrega de software (e QA!) teria sido dramaticamente mais fácil e teria melhorado muito anos atrás!!!

A boa notícia: talvez a IA não vá substituir engenheiros… mas pode finalmente nos forçar a “respeitar” a engenharia de requisitos novamente.

Agora a pergunta que persiste é: estamos melhorando a documentação porque a IA precisa… ou porque finalmente admitimos que sempre precisamos?

— Rodrigo Morteo

O ponto dele me prendeu, bom entramos na era do “vibe-coding”, onde de repente todos estão alimentando a IA com documentos de arquitetura bem estruturados, documentos de planejamento detalhados, user stories limpas com critérios de aceitação detalhados e edge cases com suas restrições também detalhadamente documentados.

O objetivo deste texto não é refutar o amigo, e sim adicionar meus pensamentos ao post dele, com mais detalhes abaixo.

A era dos requisitos

Como Dev com mais de uma década de experiência em setores bancário, varejo e e-gaming, eu vivi a arqueologia da coleta de requisitos que Rodrigo descreve. As reuniões intermináveis tentando decodificar solicitações quase sempre vagas do negócio. A abordagem “vamos saber quando virmos, ou vamos focar no quick win” (quick win me tira do sério, de verdade) para critérios de aceitação. Os refinamentos que nem sempre refinam…

IA não só recebe uma documentação melhor, na maioria das vezes fornecemos algo melhor do que damos aos desenvolvedores. Quase que o tempo todo criamos documentação pela primeira vez, especificamente para fazer prompts em ferramentas de IA. O negócio não está de repente mais articulado, e as pessoas não estão mais dispostas a fazer um ótimo trabalho na descrição de requisitos, é uma especie de engenharia reversa de clareza a partir da ambiguidade para alimentar a máquina. (preguiça?) Tanto que este texto mesmo foi revisado por alguma LLM para entregar uma gramática um pouco melhor que a que tenho usado diariamente.

Um ponto de vista apenas

Todo mundo tem acesso à IA agora. ChatGPT, GitHub Copilot, Claude… a lista vai crescendo bem rápido, a democratização foi bem rápida e a geração de código em uma escala sem precedentes aconteceu. A documentação não ficou para trás, está crescendo exponencialmente. As user stories estão mais detalhadas. Diagramas de arquitetura estão mais polidos. Pessoas que nunca viram Mermaid diagram agora conseguem entregar qualquer tipo de diagrama a partir de um prompt vago.

Mas aqui está a questão crítica que, do meu ponto de vista: Quem está supervisionando ou lendo isso de fato?

Quando desenvolvedores escreviam código a partir de requisitos vagos, pelo menos havia uma pessoa no processo interpretando, questionando, entrando em call. Quando QA testavam funcionalidades, eles aplicavam pensamento crítico em especificações ambíguas. O atrito no processo, por mais frustrante que fosse, servia como um portão de qualidade. E, honestamente, é importante esse atrito.

Aqui está uma conexão interessante entre o post e post feito pelo Simon Smart, que nao minha visão era onde ambiguidades eram resolvidas, quando tinhamos acesso aos devs e seus mapas: Quando seu codigo é um labirinto, desenvolvedores inteligentes criam mapas Uma leitura que conectado a este post mostra como interação dev testers é enriquecedora.

Agora estamos em uma situação onde:

• Desenvolvedores juniores ou não fazem prompts para IA gerar funcionalidades inteiras
• IA cria testes para código gerado por IA (sem mencionar janela de contexto)
• IA revisa código de IA
• Documentação é aprimorada por IA sem validação de expertise de domínio
• Requisitos são esclarecidos por interpretadores de IA ao invés de stakeholders do negócio ou team members.

A produtividade aumentou dramaticamente, mas de fato qualidade e as entregas estão aumentando?

Do lado dos testes e desenvolvimento

Do ponto de vista de desenvolvimento e qualidade, isso cria uma tempestade:

Processo anterior:

Requisitos vagos ou idea para POC é entregue pelos stakeholders
→ Desenvolvedores interpretam
→ QA valida interpretações erradas
→ Refinamento iterativo

Com IA:

Prompts iniciais vagos para agentes de IA geram requisitos com aparência detalhada
→ Refinamento é feito por IA, cobrindo os gaps sem validação de requisitos
→ Testes e Codigos são gerados com base nos requisitos usando IA ou Não.
→ Refinamento volta em rounds com IA antes de chegar ao stakeholder

As etapas intermediárias, o pensamento crítico, o conhecimento de domínio, o checkpoint “isso realmente faz sentido para o negócio?”, estão desaparecendo. Os deploys estão mais rápidos, as features aumentaram e eu acredito sim que a IA está se tornando cada vez mais capaz de gerar código. Mas, ainda assim, somos os agentes humanos de agentes de IA.

Eu já vi suítes de automação de testes geradas por IA que estão tecnicamente corretas, mas testam as coisas erradas. O mesmo acontece com código: dezenas de duplicações de lógica, funções deprecadas esquecidas para manter versão antiga do POC, mas que foram entregues de forma rápida e funcionam performaticamente, mas novamente, aumentam o labirinto sem criar os mapas citados pelo Simon Smart. Já revisei critérios de aceitação que parecem abrangentes, mas perdem a lógica de negócio real. A documentação existe, mas não foi validada. Não foi questionada.

Estamos Melhorando ou Apenas Performando?

Estamos criando a ilusão de documentação sem o conteúdo?

O valor real da engenharia de requisitos vão alem dos artefatos, são as conversas, as negociações, o entendimento compartilhado que emergia do processo. Quando analistas de negócio, desenvolvedores e QA sentavam juntos e martelavam o que uma funcionalidade realmente significava, era ali que a clareza vivia. (Por favor nao entenda isso como uma chamada para o trabalho presencial)

Agora estamos otimizando para consumo de IA, não para entendimento humano. Estamos criando prompts, não especificações. Estamos perdendo os modelos mentais compartilhados e talvez a clareza do que queremos alcançar.

Talvez parte disso seja a mudança cultural que tenho vivido recentemente também, sou do país do jeitinho, do contato humano que está presente em todas as interações. Mas isso é post pra outra hora.

A resposta

Simples, não a tenho. :D

Quem me conhece sabe como gosto de levantar questionamentos e não respondê-los.

A Linha de Fundo

As ferramentas de codificação com IA deixam claro algo que sempre soubemos: bons requisitos sempre foram possíveis, simplesmente não os priorizamos. Mas a solução não é gerar montanhas de documentação para consumo de IA enquanto deixamos o entendimento humano para trás. Sim, é dificil lutar contra a onda de serotonina que tem sido ver algo ser criado tão rapido e de forma aparentemente correta.

A realidade perigosa é que estamos escalando a geração de código mais rápido do que estamos escalando a supervisão e o entendimento. Todo mundo tem acesso a ferramentas poderosas de IA, mas nem todo mundo tem a experiência para saber quando essas ferramentas estão confidentemente erradas.

Como alguém que passou anos em engenharia de software e qualidade, eu sei que:

• Mais documentação ≠ melhor qualidade
• Mais testes ≠ melhor cobertura
• Mais código ≠ mais valor
• Mais velocidade ≠ Inovação

E agora José

Eu espero que a IA nos force a respeitar a engenharia de requisitos novamente, mas criar entendimento genuíno, não apenas alimentar a máquina é um desafio que dará um certo trabalho superar.

Fico aqui com o “como garantimos que pessoas continuam no centro do processo de qualidade?” ou indo até mais longe, “como mantemos as pessoas no centro de todos os processo?” uma vez que tudo, seja o que for tem um cliente que vai usar ou se beneficiar do que está sendo desenvolvido

Enfim, só mais um dump da minha cabeça.