O contrato que você assina antes de delegar ao agente

Uma linha real de fila de trabalho: "melhorar a performance da tela de pedidos". Leitura um: reduzir o tempo de resposta da porta programável que alimenta a tela. Leitura dois: reduzir o tempo até o primeiro elemento aparecer, o que pode melhorar sem a porta programável mudar nada. Um agente escolhe uma das duas em silêncio e entrega um resultado coerente com a escolha dele.

Suponha uma padaria que vende pela internet e pede ao agente "cupom de 10% no primeiro pedido". Sem fora de escopo escrito, ele decide sozinho se o cupom vale para assinatura e se acumula com outros cupons; o modelo de contrato desta aula fecha essas duas portas antes da primeira linha de código.

Entre dois regimes que costumam ser confundidos existe uma fronteira, e os dois têm nome corrente. No primeiro, engenharia assistida por IA, alguém se importa com o código e o revisa, com todas as obrigações que isso implica. No segundo, que o mercado batizou de vibe coding, ninguém olha o código e o resultado é aceito pelo comportamento observado. Saber os dois nomes importa porque eles vão aparecer numa reunião, ditos com orgulho ou como acusação.

Os dois regimes são legítimos em contextos diferentes. O segundo funciona bem em protótipo descartável e mal em qualquer coisa que alguém vá manter depois. O problema começa quando um time opera no segundo achando que está no primeiro. A especificação é o que mantém você no primeiro regime quando o volume gerado torna a leitura integral impossível.

A maturidade da prática tem três níveis: a especificação existe antes do código, a especificação é atualizada quando o código muda, e o código é gerado a partir da especificação. O salto caro é o segundo, porque manter o documento vivo exige disciplina de processo, enquanto gerar a partir dele é sobretudo ferramenta.

Existe um indício empírico de que essa é a alavanca certa, e ele vem com ressalva. Uma revisão de 67 fontes publicadas entre 2022 e 2026, cruzada com telemetria de mais de dez mil desenvolvedores, sustenta que a disciplina de especificação pesa sobre a confiabilidade do software assistido por IA acima da capacidade do modelo escolhido. A ressalva pesa e vai declarada aqui: o texto é uma pré-publicação, ou seja, ainda não passou por revisão de pares, e tem um autor só. Trate como hipótese bem argumentada, peça mais evidência antes de virar política corporativa, e note que o argumento desta aula não depende dela: decisão que ninguém escreveu vira decisão do agente, com ou sem estudo.

O ferramental de mercado converge na mesma direção. O Spec Kit, mantido em repositório aberto pelo GitHub, expõe esse encadeamento como comandos de agente. O Kiro, da AWS, padroniza requisitos na notação EARS, em que cada linha assume a forma "quando tal condição, o sistema deve tal comportamento" e vira caso de teste diretamente. Uma precisão honesta: nos dois produtos, clarificação e análise são passos opcionais recomendados, e é este curso que os promove a etapas obrigatórias.

Na PocketOS, caso contado na etapa sobre autonomia, um item em branco teve preço. Em 25/04/2026, um agente de codificação recebeu uma tarefa rotineira e esbarrou numa credencial que não funcionava. Procurou outra chave por conta própria, encontrou uma de escopo amplo em um arquivo sem relação com a tarefa e seguiu adiante. O banco de produção e os backups desapareceram em nove segundos.

Lido pelo ângulo do contrato, o caso expõe um campo vazio. Ninguém tinha escrito o que o agente deveria fazer diante de uma credencial que falha, então ele escreveu por conta. Esse campo tem nome nesta aula: política do agente, o item que declara o que ele resolve sozinho e o que ele devolve para um humano. É o oitavo dos onze, e é o que os times mais deixam para depois.

O contrato só prova o valor dele numa demanda de verdade, por isso as duas tarefas abaixo usam a sua fila real.

Contrato em uma página. Escolha um problema real do seu plano de trabalho e preencha o modelo desta aula. Cronometre. Se passar de 90 minutos, aponte onde a intenção estava vaga em vez de culpar o formato.

Auditoria de ambiguidade. Pegue três pedidos abertos na sua fila e marque cada frase que um leitor literal interpretaria de duas formas. Reescreva as três piores como critérios de aceite verificáveis.

Critérios de sucesso

• O contrato cabe em uma página e cada item tem no máximo três linhas verificáveis.
• Nenhum critério de aceite pode ser declarado cumprido sem um teste, comando ou artefato que o prove.
• As três frases reescritas sobrevivem ao teste do leitor literal: leia cada uma tentando interpretá-la errado de propósito.