Engenhariaכֵּלִים
Ferramentas de IA para engenharia: sabedoria, entendimento e ofício
As quatro camadas de uma ferramenta de IA séria, o MCP como contrato de acesso, RAG que cita a fonte e avaliação que reprova o pull request.
כְּכֹל אֲשֶׁר אֲנִי מַרְאֶה אוֹתְךָ אֵת תַּבְנִית הַמִּשְׁכָּן
kechol asher ani mar'eh otcha et tavnit hamishkan · conforme tudo o que eu te mostro, a planta do Mishkan · Shemot 25:9
Blog/Artigos · Engenharia
Desenvolvimento orientado a especificação: a planta do Mishkan antes da madeira
Requisito em EARS, design, tarefas e rastreabilidade até o teste, com a IA executando a spec e a pessoa aprovando cada fase.
O Mishkan não foi construído a partir de uma ideia geral. Antes de qualquer madeira ser cortada existia uma tavnit, uma planta mostrada em detalhe, com medida, material e ordem de montagem. Com IA gerando código em volume, a planta volta a ser a parte mais valiosa do trabalho de engenharia. Um modelo executa muito bem uma especificação clara, e inventa com a mesma confiança quando a especificação é vaga.
A planta antes da madeira
Desenvolvimento orientado a especificação separa o trabalho em fases com aprovação explícita: requisitos, design, tarefas e só então implementação. Cada fase produz um documento que a pessoa revisa e aprova antes de a próxima começar. A IA acelera todas as fases, e a aprovação humana fica em cada fronteira.
A diferença prática aparece na revisão. Revisar um pull request de mil linhas geradas a partir de um pedido solto é adivinhar a intenção. Revisar o mesmo PR contra uma lista de requisitos numerados e de tarefas que citam esses requisitos é conferir, item por item, se o que foi pedido foi feito.
Figura 1Fases do desenvolvimento orientado a especificação
- 01IARequisitoshistórias com critérios de aceite em EARS
- 02IADesignarquitetura, interfaces, modelo de dado e propriedades de correção
- 03IATarefaspassos pequenos, cada um citando os requisitos que atende
- 04IAImplementaçãocódigo e teste gerados tarefa por tarefa
- 05Verificaçãotestes derivados dos critérios de aceite, rodando no CI
mudança de requisito entra pela spec, e o código acompanha a partir dela.
EARS: requisito que dá para testar
EARS, sigla de Easy Approach to Requirements Syntax, é um conjunto pequeno de padrões de frase para requisito. Cada padrão tem gatilho, condição e resposta em posições fixas, o que elimina a maior parte da ambiguidade de texto livre e deixa o requisito pronto para virar teste.
São cinco padrões: ubíquo, orientado a evento, orientado a estado, comportamento indesejado e funcionalidade opcional. Em português eu mantenho as palavras-chave em maiúscula para facilitar a leitura e a busca.
Figura 2Os cinco padrões de EARS aplicados a um serviço de pagamento
Ubíquo O serviço de extrato DEVE registrar cada consulta
com o identificador do solicitante.
Evento QUANDO um pagamento for recusado,
o serviço DEVE devolver o código de motivo em até 200 ms.
Estado ENQUANTO o antifraude estiver indisponível,
o serviço DEVE enfileirar a transação sem aprovar.
Indesejado SE o token de acesso estiver expirado,
ENTÃO o serviço DEVE responder 401 sem consultar o banco.
Opcional ONDE a conta tiver MFA ativo,
o serviço DEVE exigir o segundo fator no login.Rastreabilidade de ponta a ponta
Rastreabilidade é poder responder, para qualquer linha de código, qual requisito ela atende, e para qualquer requisito, qual teste prova que ele está atendido. Em ambiente regulado essa resposta é exigência de auditoria. Em qualquer ambiente, ela é o que permite mudar um requisito sabendo exatamente o que vai quebrar.
O elo que costuma faltar é a propriedade de correção. Entre o requisito em texto e o teste existe uma afirmação formal sobre o comportamento, como para toda transação recusada existe um código de motivo. Essa afirmação vira teste baseado em propriedade, que gera centenas de casos e encontra o canto que o teste de exemplo esquece.
Figura 3Cadeia de rastreabilidade, do requisito à evidência
- Requisito REQ-3.2QUANDO um pagamento for recusado, o serviço DEVE devolver o código de motivo
- Propriedade P-7para toda transação recusada, a resposta contém um código de motivo válido
- Teste PBTteste baseado em propriedade, com geração de transações recusadas
- Tarefa e commit T-12a tarefa cita REQ-3.2 e P-7, e o commit cita a tarefa
- Evidência CIo PR mostra o teste da propriedade verde e a cobertura do requisito
Prompt solto e especificação, lado a lado
Pedir código direto para a IA funciona para protótipo, script de uma vez e exploração. O problema começa quando o protótipo vai para produção com o mesmo processo. A especificação custa uma parte do tempo no começo e devolve esse tempo na revisão, na manutenção e na conversa com auditoria.
A comparação abaixo é a que eu uso para decidir qual abordagem cabe em cada caso. Nenhuma das duas está errada; o erro é usar a primeira onde o contexto pede a segunda.
Figura 4Pedido direto ao modelo e desenvolvimento orientado a especificação
| Aspecto | Pedido direto ao modelo | Orientado a especificação |
|---|---|---|
| Bom para | protótipo, exploração, script descartável | sistema que vai para produção e precisa de manutenção |
| Ambiguidade | resolvida pelo modelo, em silêncio | levantada na fase de requisitos e resolvida por quem pediu |
| Revisão | leitura do código tentando inferir a intenção | conferência do código contra requisitos numerados |
| Teste | escrito depois, quando escrito | derivado dos critérios de aceite e das propriedades |
| Mudança de escopo | novo pedido, contexto perdido | requisito alterado, impacto rastreado até o código |
| Auditoria | difícil explicar por que o sistema faz o que faz | cada comportamento tem requisito, teste e evidência |
O papel da IA em cada fase
Em todas as fases a IA redige e a pessoa aprova. O que muda de uma fase para a outra é o tipo de julgamento que a aprovação exige. Em requisitos, o julgamento é de negócio. Em design, de arquitetura e risco. Em tarefas, de sequência e tamanho. Em implementação, de aderência ao que foi aprovado antes.
Essa divisão também muda o que se espera do time. A habilidade mais valiosa passa a ser escrever e revisar especificação, e é a mesma habilidade que sempre separou engenheiro sênior de pleno: saber o que perguntar antes de construir.
Figura 5O que a IA faz e o que a pessoa aprova, fase a fase
- REQUISITOSIA redige histórias e critérios em EARSa pessoa aprova escopo, prioridade e o que ficou de fora
- DESIGNIA propõe arquitetura, interfaces e propriedadesa pessoa aprova decisões de risco, segurança e custo
- TAREFASIA quebra o design em passos rastreáveisa pessoa aprova ordem, tamanho e dependências
- CÓDIGOIA implementa tarefa por tarefa, com testea pessoa revisa contra requisito e tarefa, no PR
- VERIFICAÇÃOIA aponta lacunas de rastreabilidadea pessoa decide se a lacuna bloqueia a entrega
- MUDANÇAIA mede o impacto de alterar um requisitoa pessoa aprova a alteração e o novo prazo
Para levar
Com IA escrevendo código em volume, a especificação vira o artefato principal do engenheiro. Requisito em EARS, design com propriedades de correção, tarefas rastreáveis e teste derivado do critério de aceite. A IA executa a planta com rapidez; quem aprova a planta continua respondendo pelo que foi construído.
Quem escreve: Juliano Vince de Campos
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
