O que é o SPELL
O problema que o SPELL resolve
Todo sistema começa com uma especificação. O problema é que especificações escritas em Markdown, Notion ou documentos de texto são inerentemente informais: não há sintaxe obrigatória, não há compilação, não há verificação. O resultado prático é que projetos chegam em produção diferentes do que foi aprovado.
Com a ascensão dos agentes de IA geradores de código, o problema ganhou uma dimensão nova. Quando a especificação é vaga ou inexistente, a IA preenche os vazios por conta própria — e preenche de forma consistente com seus padrões de treinamento, não com as decisões do seu negócio. Regras de negócio críticas não declaradas simplesmente não aparecem na implementação. E não há como auditar o que não foi escrito.
Três sintomas recorrentes em equipes sem especificação formal:
- A IA implementa um comportamento diferente do que o arquiteto tinha em mente, mas ninguém consegue apontar onde a spec dizia o contrário
- Decisões arquiteturais importantes vivem no histórico de chat e somem com a rotatividade de equipe
- A mesma funcionalidade é implementada de formas diferentes em módulos diferentes porque cada sessão começa do zero
O que é o SPELL
SPELL (Spec Programming & Execution Logic Language) é uma linguagem estruturada de especificação de software. Arquivos .spell são compilados pelo spellcomp em arquivos .md que qualquer agente de IA usa como contrato de implementação.
O elo que o SPELL estabelece é simples: o arquiteto descreve o que o sistema deve fazer; a IA decide como implementar. A spec compila, é auditável e sobrevive à rotatividade de equipe. O que foi aprovado fica registrado de forma verificável — não num documento que alguém pode editar à mão sem rastreabilidade.
Dados {
table Usuario {
nome: texto(100), obrigatorio
email: texto(200), unico, obrigatorio
ativo: booleano, padrao: sim
}
}
Regras {
rule SenhaForte {
contexto: Cadastro de usuário
condicao: Senha informada tem menos de 8 caracteres
acao: Recusar o cadastro com mensagem de requisito mínimo
/// Bloquear também senhas comuns como "123456" e "senha"
}
}Esse arquivo compila em instruções precisas para o agente. A regra SenhaForte não é inferida pela IA — ela está declarada, com contexto, condição e ação explícitos. Se a regra não estiver na spec, ela não existe no sistema.
O que o SPELL não é
O SPELL não é uma linguagem de programação. Ele não gera código — gera instruções. O arquiteto não precisa saber programar para usar o SPELL. Ele precisa saber descrever o negócio.
O SPELL também não é um substituto para a IA. Ele é o contrato que a IA executa. A linguagem deliberadamente deixa a decisão de "como" para o agente: escolha de algoritmos, estrutura interna de funções, otimizações de performance. O que o arquiteto decide é o "o quê" e o "por quê".
Diferenças importantes:
| SPELL é | SPELL não é |
|---|---|
| Uma linguagem de especificação | Uma linguagem de programação |
| Compilado em instruções para IA | Executado diretamente |
| Focado no "o quê" e no "por quê" | Focado no "como" implementar |
| Escrito pelo arquiteto de negócio | Escrito pelo desenvolvedor |
| Auditável e versionável como código | Um documento de texto informal |
Público-alvo
O público-alvo do SPELL são CTOs e tech leads, não desenvolvedores individuais.
A dor que o SPELL resolve é organizacional: projetos que chegam em produção diferentes do que foi aprovado, especificações que vivem no histórico de chat e somem com a rotatividade de equipe, decisões arquiteturais tomadas pela IA sem autoridade para isso.
O argumento mais forte para adoção: a spec compila, é auditável e sobrevive à rotatividade de equipe. Quando o tech lead que tomou a decisão de usar UUID como chave primária sai da empresa, a decisão continua documentada e enforçada.
Desenvolvedores podem adotar o SPELL de forma bottom-up, mas o benefício principal é sentido no nível de gestão de projeto — quando o produto entregue corresponde ao que foi aprovado.
Os quatro princípios do SPELL
A linguagem é construída sobre quatro princípios inegociáveis:
estrutura: recomendar numa tabela e a IA infere os campos. O nível de detalhe é proporcional ao conhecimento disponível.
Como o SPELL funciona na prática
O fluxo de trabalho com o SPELL tem três etapas:
- O arquiteto escreve a spec em arquivos
.spell, descrevendo dados, regras, endpoints e telas usando a sintaxe da linguagem. - O compilador processa a spec com
spellcomp compile ., valida a sintaxe, aplica auditorias e gera arquivos.mdpor tipo de bloco. - O agente de IA executa a partir dos arquivos gerados, implementando o sistema de acordo com as instruções compiladas.
Os arquivos gerados são artefatos de build — assim como bytecode ou bundles JavaScript, eles não devem ser editados manualmente. Se algo precisar mudar, a alteração vai na spec e o projeto é recompilado.