Especificação Conversacional Estruturada

Uma visão geral sobre como preservar a intenção do negócio no desenvolvimento de software impulsionado por IA.

Agentes de IA interpretam instruções, consultam arquivos, propõem alterações, geram código e executam testes. Isso reduz o esforço de implementar, mas não garante que a solução corresponda ao problema que deveria resolver.

Quando o agente encadeia tarefas, uma interpretação incompleta atravessa vários artefatos antes de alguém percebê-la. O risco não é só o código errado: é uma interpretação ainda não validada virar uma implementação aparentemente consistente. Em sistemas legados (sistemas antigos que seguem em produção), o conhecimento de negócio está espalhado entre código, integrações, documentação desatualizada e a memória de poucas pessoas.

Nem o ganho de velocidade é consenso. Em uma tarefa controlada, desenvolvedores com IA terminaram mais rápido (Peng et al., 2023). Em um estudo com 16 desenvolvedores experientes e 246 tarefas reais, o uso de IA aumentou o tempo em 19% (Becker et al., 2025, preprint, ainda sem revisão por pares). Esta página não trata de velocidade, e sim do que se perde entre a conversa e o código.

O cenário, construído para esta página, é a modernização de um sistema comercial com mais de 15 anos: propostas, condições comerciais, aprovações, contratos e integração com o faturamento. As mudanças levam semanas, e poucas pessoas conhecem todas as regras. A diretoria pede:

A frase expressa uma intenção legítima, mas não diz o que preservar, o que mudar nem como medir o sucesso. Ela junta sintomas, necessidades a investigar, objetivos e uma solução já escolhida, e cada categoria pede um tratamento diferente.

Há uma segunda causa, decisiva em legado: o comportamento atual do sistema não é necessariamente o comportamento desejado. Uma regra pode ser preservada, corrigida, substituída ou descontinuada, e a decisão depende de evidência e de autoridade de negócio, não do que o código executa hoje.

O pedido vira, então, uma sequência de decisões. Em cada etapa há um ponto em que a IA ajuda e outro em que ela pode distorcer, mapeados em Etapa por etapa.

O modelo pode perguntar, resumir, propor cenários, apontar contradições, recuperar contexto e preparar mudanças. Por padrão, não recebe autoridade para decidir valor, risco, conformidade, aceitação ou verdade de domínio. A posição é compatível com as atividades de elicitação, análise, validação e gestão descritas na ISO/IEC/IEEE 29148 e no SWEBOK (o guia de conhecimento de engenharia de software da IEEE Computer Society). A proposta explora como a IA pode apoiar essas atividades, sem substituí-las.

Quem conhece Design Thinking reconhece quatro das cinco etapas. A quinta, especificar e evoluir os artefatos, é o acréscimo da engenharia de requisitos. Em cada etapa o ganho vem junto com um risco conhecido e um controle. É um ciclo, não uma sequência: qualquer etapa volta à anterior quando surge evidência nova. O vocabulário do Design Thinking serve de mapa; não é apresentado como prova de nada.

Nesta proposta, a contribuição do modelo só conta quando suas saídas podem ser examinadas e contestadas. Comece por um fluxo representativo, não pelo sistema inteiro. No cenário, a aprovação de proposta com desconto excepcional.

Não é burocracia para cada frase: é conseguir distinguir o que se sabe, o que se supõe e o que se decidiu. E validar o entendimento não é validar o resultado. A conversa pode revelar se as pessoas entendem a regra de jeitos diferentes, não que a modernização vai reduzir incidentes.

A matriz separa autoridade de assistência. É uma política de governança proposta, a ajustar à estrutura de responsabilidade de cada organização, e não uma exigência de norma.

Quando o agente também executa ferramentas, altera arquivos ou aciona pipelines, os controles passam a cobrir permissões, escopo de execução, revisão de mudanças e condições de interrupção: gerar uma sugestão e executar uma ação são níveis diferentes de autonomia. A linha dos critérios de aceite liga esta seção a TDD: a IA pode escrever o código do teste, mas o resultado esperado vem de quem tem autoridade sobre a regra.

Cada artefato tem uma responsabilidade e um limite. As regras de negócio registram políticas aprovadas, mas não garantem a implementação. Os testes de caracterização registram o legado, inclusive defeitos e regras obsoletas. O código implementa uma versão, mas não comprova aderência à intenção. Não há fonte universal de verdade.

A divergência (em inglês, drift) é a situação em que artefatos que deveriam dizer a mesma coisa passam a dizer coisas diferentes. A política proposta tem cinco passos, mostrados abaixo no exemplo do desconto.

O caso inverso: se o código novo não satisfaz um critério aprovado, mudar o critério exige decisão explícita. Editar o teste para ele passar é uma decisão sem registro. A rastreabilidade vale nas duas direções (decisão → critério → teste → componente; falha → regra a revisar), com profundidade proporcional à criticidade e à exigência de auditoria. O objetivo não é impedir toda divergência, mas torná-la detectável, explicável e tratável.

Um termo antes de seguir: critérios de aceite são a fonte do resultado esperado com o qual o teste compara o comportamento observado.

A diferença entre as abordagens é a unidade de controle. O TDD (escrever um teste que falha, o código mínimo para ele passar, e então refatorar) responde “qual é o próximo menor incremento e como verifico que ele continua funcionando?”. A especificação responde “qual problema, para quem, com quais regras, restrições e critérios?”. O TDD torna o feedback barato; não torna os critérios de aceite corretos. Sem intenção e escopo, o TDD pode testar a coisa errada com eficiência. Sem critérios de aceite executáveis, a especificação pode documentar uma intenção errada.

Há um risco específico de agentes: quando o mesmo modelo escreve a especificação e os testes, um teste verde pode apenas confirmar o erro do próprio modelo. O controle é o resultado esperado ser definido ou validado por pessoas antes de o teste ser gerado (a linha dos critérios de aceite em Quem decide o quê), e cada critério crítico ter ao menos um teste que não nasceu do mesmo prompt nem do mesmo contexto.

Em legado, três tipos de teste têm papéis diferentes: caracterização (o que o legado faz hoje), aceitação (os critérios aprovados) e TDD (a implementação local). Uma sequência possível: caracterizar o legado, validar as regras com quem decide, escrever testes de aceitação, implementar com TDD, comparar resultados e liberar com monitoramento, critério de interrupção e reversão.

A evidência sobre o TDD é maior que a deste workflow, e contextual. Rafique & Mišić (2013), em uma meta-análise de 27 estudos, encontraram efeito pequeno em qualidade e pouco ou nenhum em produtividade. Tosun et al. (2017), com 24 profissionais, não acharam diferença estatística de qualidade externa e viram queda de produtividade na tarefa complexa em código existente. Nagappan et al. (2008), em quatro equipes de IBM e Microsoft, observaram densidade de defeitos 40–90% menor e 15–35% mais tempo de desenvolvimento, com ameaças à validade declaradas pelos autores. Liu et al. (2023, EvalPlus) mostraram que testes ampliados encontram erros que os testes originais deixam passar. A conclusão é que a proposta não reivindica superioridade sobre o TDD nem o substitui: fornece contexto e decisões; o TDD fornece feedback local e proteção contra regressão.

Uma modernização não está concluída porque o código foi reescrito. Os indicadores abaixo precisam de definição operacional, linha de base e período de observação; mais documentos ou testes não provam, sozinhos, que o sistema ficou mais sustentável. As definições completas (recall de requisitos, ambiguidade residual por 100 requisitos, precisão e recall de links, métricas DORA) estão no kit.

Subir um degrau exige evidência nova; o degrau de baixo não prova o de cima.

LLMs mostram capacidade parcial em tarefas controladas de elicitação, geração de especificação e detecção de ambiguidade, com falhas em terminologia de domínio, interfaces e restrições. A pesquisa é majoritariamente de laboratório, e LLMs como revisores de requisitos tiveram resultados inconsistentes. Não foi localizado estudo controlado ou longitudinal do workflow completo frente a uma linha de base alinhada à ISO/IEC/IEEE 29148 e ao SWEBOK.

Escolha um fluxo representativo, aplique as cinco práticas, registre a primeira divergência e decida quem a resolve. Sem promessa de resultado: o objetivo é ter algo que possa ser examinado e contestado.

Normas e guias são fundamento do desenho, não experimento: nenhuma delas valida este workflow. As referências estão agrupadas pelo tipo de evidência.