“Envie amanhã às nove” parece uma instrução suficiente até você precisar definir qual fuso horário o sistema deve usar. O cliente está em São Paulo, o servidor usa outro fuso e a mensagem pode ser cancelada durante a espera. Quando as specs não definem esses comportamentos, um agente pode escolher uma interpretação e transformá-la em código.

Eu prefiro levar essas escolhas para a especificação. Assim você consegue discutir o comportamento do produto sem procurar cada interpretação dentro da implementação gerada. As specs registram o que o sistema deve fazer numa situação conhecida.

Direto ao ponto

As specs são especificações que descrevem o comportamento esperado de uma funcionalidade. Com agentes de código, elas permitem orientar a geração e verificar uma implementação a partir da mesma descrição. A sintaxe continua necessária para executar o sistema, enquanto você descreve a intenção e as condições da tarefa em linguagem natural.

No agendamento, a especificação precisa indicar o fuso adotado e o comportamento de cancelamento. Também deve explicar a resposta quando o serviço de mensagens não confirma o envio. Uma descrição que só repete “agendar mensagens” deixa essas escolhas para a implementação, seja ela escrita por você ou pelo agente.

O fuso horário definido nas specs

Considere um sistema hipotético que permite programar uma mensagem para um contato. O cliente escolhe a data e o horário no formulário. A aplicação registra o instante de execução e o exibe novamente na confirmação.

A descrição pode afirmar que o horário será interpretado no fuso configurado para aquela empresa. Com o fuso da empresa definido como UTC−3 no exemplo, um envio às nove corresponde ao meio-dia em UTC (Tempo Universal Coordenado). A confirmação precisa voltar a mostrar nove horas para o cliente. Esses dois horários permitem verificar a conversão e a apresentação do mesmo agendamento.

Escrever essa descrição em português ou em inglês não muda a necessidade de indicar o fuso. O agente pode interpretar qualquer uma das línguas, mas não recupera uma escolha do produto que ficou ausente. A descrição do fuso permite testar a conversão, enquanto repetir a importância do envio pontual deixa essa definição ausente.

O artigo sobre construir com IA além do código aprofunda a relação entre intenção e implementação. Nesse exemplo, a contribuição da especificação é permitir que você examine o significado do horário na descrição da tarefa, acompanhando depois sua tradução para o código.

Cancelar durante a espera ou durante o envio

Um agendamento pendente pode receber o cancelamento e sair da execução programada. Depois que o serviço começa a transmitir a mensagem, a aplicação talvez já não consiga interromper essa tentativa. A interface precisa distinguir essas situações para não prometer uma ação que o sistema deixou de controlar.

Para mim, esse trecho merece uma descrição própria. O botão “cancelar” permanece simples na tela, mas a resposta depende do estado do envio. A especificação pode delimitar que a confirmação de cancelamento só aparece depois de o estado registrado impedir o início do envio. O executor precisa respeitar esse estado mesmo que já tenha buscado o item para processar.

O teste com o agendamento aguardando execução confirma o cancelamento aceito. Outra tentativa, realizada depois de iniciar o envio, deve produzir o retorno previsto para um trabalho já iniciado, em vez de copiar a mensagem de sucesso da primeira situação.

Uma mudança descoberta nessa conferência também altera a descrição. Manter a especificação antiga enquanto o código usa outro comportamento deixa a próxima tarefa com duas referências incompatíveis. O documento precisa acompanhar a funcionalidade aceita, sem preservar uma promessa que o produto deixou de cumprir. O artigo sobre repertório técnico com IA acompanha outro caso de solicitações que disputam o mesmo registro.

Uma resposta ausente não confirma um envio cancelado

Durante a transmissão, a conexão pode cair e impedir o retorno do serviço. Você sabe que a tentativa começou, mas ainda não sabe se a mensagem chegou. O agendamento precisa representar essa situação sem informar automaticamente que nada foi enviado.

Repetir a tentativa pode produzir uma duplicação. A especificação deve indicar como a aplicação acompanha a tentativa anterior, conforme o serviço integrado permite. Uma identificação persistente da tentativa pode permitir consultar o resultado ou reconhecer um envio já processado. Esse comportamento precisa corresponder aos recursos reais da integração. O artigo sobre ferramentas MCP para o assistente do cliente examina a separação entre consultar um histórico e autorizar uma mensagem.

O agente pode implementar a repetição de um envio ao encontrar uma falha de rede. Sem a descrição dessa situação, a solução pode parecer coerente numa leitura isolada e produzir duas mensagens para o cliente. A revisão de código gerado por IA permite localizar essa interpretação nos arquivos alterados.

Uma especificação que cabe numa tarefa

O envio individual e seu cancelamento formam uma funcionalidade delimitada. Acrescentar distribuição para grupos muda o conjunto de destinatários e a forma de acompanhar os resultados. Você pode manter esse trabalho em outra tarefa, evitando que a implementação inicial inclua comportamentos que ainda não foram discutidos.

A descrição também precisa dizer que o envio para grupos está fora dessa versão. Isso permite distinguir uma ausência intencional de uma funcionalidade incompleta. O agente recebe o envio individual como limite da implementação, permitindo que você recuse código acrescentado para distribuir mensagens a grupos.

Para essa funcionalidade, eu manteria o exemplo de horário e os dois estados de cancelamento junto dos testes correspondentes. Você consegue reler a especificação e encontrar o comportamento que motivou cada teste, sem repetir o objetivo geral em todas as seções.

A Formação Vibe Coding da Promovaweb, presente no caminho de estudo do Plano IA Makers da Promovaweb, se relaciona à construção dessas tarefas com agentes. Quando um sistema existente tem funcionalidades misturadas e precisa organizar a sequência de implementação, o Diagnóstico de Produto e Arquitetura da Dev Side Studio oferece uma análise do produto.