Como criei o OMLA: direcionando agentes de IA em vez de escrever o código

Este é exatamente o processo que usei para fazer agentes de codificação de IA construírem, quase sozinhos, o OMLA – o backend de licenciamento de royalties de uma organização sem fins lucrativos. Use esse método também. O backend final é apenas a prova de que funciona.

O que se obtém no final

Antes de qualquer tutorial, eis o resultado final: a OMLA, a Open Model Licensing Association. Um sistema de licenciamento e um site público para modelos de IA abertos.

O que	Resultado
Status	Em processo de organização como uma organização sem fins lucrativos em Washington; o status 501(c)(3) ainda está pendente. O site exibe propositalmente a marca “Beta 0.9.0”.
Termos de uso	Gratuito para uso pessoal, acadêmico e de pesquisa. Para uso comercial, cobra-se 30% do valor maior entre a receita obtida e o custo de execução do modelo.
Banco de dados	12 tabelas principais; Postgres 17 rodando no Supabase. Segurança em nível de linha, cálculos financeiros feitos em centavos inteiros (nunca usando números de ponto flutuante).
Identidade digital	Sistema híbrido de assinaturas: ed25519 + ML-DSA-65; combina criptografia clássica e pós-quântica, para que um eventual ataque quântico não comprometa o sistema. Sem assinatura verificada, não há emissão de comprovantes de pagamento.
Registro de auditoria	Sistema somente anexável; cadeia de hashes SHA-256 verificada a cada hora. Um “âncora” diária da ponta da cadeia é armazenada fora do banco de dados.
Frontend	Cerca de 30 páginas HTML estáticas, sem frameworks; disponíveis em 13 idiomas, hospedadas em servidores compartilhados comuns.
Quem desenvolveu	Uma pessoa apenas coordenando as tarefas; o Claude Code escreveu o código; um enxame de agentes locais de modelos abertos realizou revisões e tarefas repetitivas.
Situação atual (julho de 2026)	Tudo já foi preparado e testado. O deploy só será feito após eu digitar “GO” pessoalmente.

Cronograma aproximado, caso você ache que tudo aconteceu num único fim de semana:

• Fim de maio de 2026 — mudança de rumo: do projeto pessoal de chatbot para uma organização sem fins lucrativos voltada ao licenciamento; definição do esquema inicial com 12 tabelas.
• Em poucos dias — implementação de assinaturas pós-quânticas, funções relacionadas ao processamento financeiro e a reescrita do sistema para eliminar qualquer tipo de custódia de dados (mais detalhes abaixo).
• Início de junho — backend colocado em produção (o banco de dados, não o frontend público).
• 16 de junho — reescrita legal concluída; a Licença v1.0 entra em vigor.
• 2 de julho — atualização completa do site e do backend, além de nova tradução para 13 idiomas; tudo já testado, mas aguardando meu sinal “GO” (julho de 2026).

Curiosidade sobre a origem: OMLA originalmente significava “Open Machine Learning Assistant”, um projeto pessoal de chatbot. As escolhas de infraestrutura foram mantidas na transição para o modelo de licenciamento; o chatbot acabou se tornando um assistente de documentação de escopo limitado, que é propositalmente desativado em produção. Transformar um chatbot de hobby numa infraestrutura de licenciamento? Isso é um grau normal de expansão de escopo, certo?

A regra que tornou tudo possível

Uma única decisão de design fez a maior parte do trabalho, antes mesmo de qualquer código ser escrito: o OMLA nunca move, retém ou transmite dinheiro. Ele calcula o valor devido e publica as informações de pagamento fornecidas pelo próprio beneficiário. O usuário comercial paga diretamente ao criador, de forma peer-to-peer. Sem processamento de pagamentos, sem depósito em garantia, sem “saldo OMLA”. Os identificadores das carteiras são apenas informações de roteamento, não contas propriamente ditas.

O texto da licença diz isso claramente: “O OMLA publica; o OMLA não paga.”

Por que fazer isso? Ser uma entidade transmissora de dinheiro implica um pesadelo regulatório, além das exigências de licenciamento. Ao dispensar a custódia dos fundos, o ônus relativo à KYC, sanções e questões fiscais passa para as duas partes envolvidas na transação — que é, aliás, onde esse ônus deve legalmente ficar. Essa única decisão é o motivo pelo qual até mesmo um hobbyista solitário pôde tentar desenvolver este projeto.

Na verdade, essa não era a ideia original. Durante o desenvolvimento, o esquema de banco de dados ainda sugeria a existência de custódia dos fundos; por isso, uma tabela chamada literalmente payments teve seu nome alterado para royalty_statements. Houve toda uma migração de colunas, índices, gatilhos, políticas de segurança e enums, só para fazer com que o banco de dados parasse de “mentir” sobre suas funções. O texto antigo acabou voltando para me causar problemas mais tarde (veja as armadilhas).

Abaixo, vemos o caminho que um dólar de royalty percorre, sem que o OMLA jamais detenha esse dinheiro.

O passo 4 é o gatilho: sem uma assinatura verificada no passo 1, não há como gerar um demonstrativo de royalties. O OMLA publica apenas o valor devido e as informações da carteira; depois disso, tudo fica a cargo das duas partes envolvidas — é como se eu lhe dissesse que um amigo lhe deve vinte dólares e deixasse vocês dois resolverem isso sozinhos.

O ciclo real: humano, agentes, verificação, implantação

O fluxo de trabalho não é complicado. É apenas rigoroso quanto a quem faz o quê; esse ciclo se repete toda vez que algo muda.

O importante não são as caixas do diagrama, mas o fato de que nada pode pular nenhuma etapa. Cada mudança começa comigo definindo o que deve existir e por quê; nunca basta apenas “melhorar algo”. Os agentes elaboram o trabalho conforme essa especificação; outros agentes auditam esse rascunho antes mesmo de eu vê-lo, e os testes são executados num ambiente real. Só então eu analiso as alterações.

Todo o backend roda primeiro localmente: um ambiente Supabase real, com Postgres 17 e funções edge, tudo em contêineres sem privilégios na minha própria máquina. O ambiente de produção é apenas um alvo para implantação; nunca a fonte da verdade. Se o comportamento local e o de produção divergirem, o de produção está errado até que eu faça uma nova implantação.

O padrão de qualidade está definido na configuração do projeto, não apenas na minha cabeça: “Pronto para auditoria por padrão: entregue trabalhos capazes de resistir a auditorias externas.” Tudo é feito partindo do pressuposto de que um revisor independente, seja IA ou humano, tentará encontrar falhas posteriormente.

Testes contra um ambiente real, não um mock

Nada disso importa se os testes estiverem mentindo para você; por isso, nada aqui é executado contra um banco de dados fictício. Tudo roda contra um ambiente local real e descartável. Três camadas, todas funcionando corretamente antes que qualquer coisa seja enviada para deploy:

deno test                  # 13 unit tests for the edge functions
./test/run.sh              # isolated scratch DB per run, migrations w/ ON_ERROR_STOP,
                            # smoke tests (PQ signatures, wrong-key rejection, audit
                            # hash-chain, payout gate), RLS cross-tenant isolation,
                            # an adversarial suite, then rollback + reapply
./test/integration.sh      # the full money path against the live local stack:
                            # register → tampered payload rejected → wallet verify →
                            # splits → usage report → statement published → replay
                            # (asserts zero duplicate writes) → admin gate → compliance

Aquele trecho “replay que garante zero escritas duplicadas” é mais importante do que parece. Os relatórios de uso vêm dos sistemas de outras pessoas; por isso, eventualmente um deles é reenviado por acidente. O teste verifica se a reprodução do mesmo relatório resulta em zero novas entradas no banco de dados, e não apenas se nada dá errado. Posteriormente, o conjunto de testes foi aprimorado para validar os resultados em vez de apenas registrar informações — algo que parece excessivamente meticuloso, até você precisar depurar um teste que “passou” mas na verdade não fez nada.

Auditorias que avaliam outras auditorias

Uma IA revisando seu próprio trabalho acaba sendo apenas uma formalidade. Por isso, as auditorias são feitas em camadas: agentes locais realizam uma primeira análise, e depois um modelo mais robusto executa uma auditoria final e independente.

Essa etapa final não é meramente simbólica. Em uma única passada, ela verificou as correções feitas pelos agentes locais e ainda encontrou um problema de desvio no caminho de busca, além de falhas nas informações sobre colunas, assinaturas e linhagem dos dados – detalhes que a primeira análise havia deixado passar. Isso resultou em uma série de correções necessárias: doze itens identificados, cada um acompanhado de um teste de regressão para garantir que esses problemas não voltassem a ocorrer.

A escala da auditoria varia conforme a complexidade das mudanças. Tarefas rotineiras recebem uma revisão feita por um painel de três agentes. Já a reformulação completa do frontend e da internacionalização contou com a participação de 24 agentes, que detectaram que o site ainda descrevia o antigo produto de chatbot, em vez do novo sistema de licenciamento; isso forçou uma reconstrução total para alinhar o site à realidade atual.

O “gate” de implantação: execução de teste até eu digitar “GO”

O executor de implantações tem uma única função: garantir que nada acima desta linha chegue à produção por acidente. Por padrão, ele executa sempre um teste preliminar; a produção só é afetada quando se usa um sinalizador explícito — o mesmo padrão de “teste preliminar e depois GO” que uso para permitir que agentes publiquem este site:

./deploy.sh              # dry run (default) — shows exactly what WOULD happen
./deploy.sh --go         # only a human runs this, only when ready

O wrapper guiado vai ainda mais longe: você precisa digitar literalmente “GO” antes de qualquer etapa que altere a produção. E existe também uma regra fixa, escrita para deixar de ser apenas uma sugestão: nunca adicione --go sem uma instrução humana explícita.

Existem outras garantias embutidas no executor, além das políticas escritas:

• A sincronização do frontend nunca usa --delete, então não pode apagar arquivos no servidor que ele não gerencia
• Um backup do lado do servidor é feito antes de qualquer sobrescrita no frontend
• O backend se recusa a agir a menos que o projeto vinculado corresponda ao projeto de produção esperado — uma proteção rígida contra envios para o banco de dados errado
• Apenas migrações aditivas são executadas no ambiente remoto; nunca ocorre nenhum tipo de reset
• Por princípio, a função do chatbot de documentação é excluída de todas as implantações
• As chaves secretas ficam apenas em um arquivo com permissões 600, fora do repositório; uma verificação em texto simples confirma que a chave de autenticação nunca aparece no conteúdo enviado para produção

Para ser honesto, o log de implantações deste projeto é basicamente um diário dos meus momentos de hesitação: teste após teste, enquanto um redesign completo aguardava a minha autorização. Isso não é um bug. É exatamente como um “gate” de implantação deve funcionar.

Armadilhas comuns

Os pontos problemáticos:

• O byte de largura zero. O SQL de migração deve ser puramente em ASCII. Um único byte não-ASCII invisível pode dividir um token do tipo $$ e, silenciosamente, fundir duas instruções SQL. A solução tornou-se um ritual: procurar por bytes não-ASCII (que devem ser zero) e contar os tokens $$ (que devem ser um número par), a cada vez.
• Sinais de porcentagem causam problemas. Numa string de formato do tipo RAISE EXCEPTION, o %% representa um sinal de porcentagem literal; cada valor precisa exatamente de um %. Isso já me pegou uma vez; esse é o motivo pelo qual está descrito aqui.
• SECURITY DEFINER exige um search_path fixo. Todas as funções definidas como SECURITY DEFINER têm seu caminho de busca fixado, para que ninguém consiga “esconder” uma tabela em pg_temp e inserir dados errados. O teste de segurança conta essas funções; se o número diminuir, o teste falha.
• O superusuário às vezes some. Após uma reinicialização inadequada, a conta do Postgres local às vezes volta sem privilégios de superusuário. A solução é simples: reiniciar o serviço; não há necessidade de troubleshooting. Anotei isso para que os agentes não precisem redescobrir esse fato.
• O mecanismo de i18n sobrescreve o HTML silenciosamente. A camada de tradução substitui todo o conteúdo da página; portanto, “corrigir” o HTML pode não adiantar se o arquivo de localização também não for atualizado. Foi assim que textos antigos continuaram aparecendo mesmo após terem sido supostamente removidos.
• A cadeia de auditoria pode ser enganada, de propósito; nós sabemos disso. Um atacante com controle total sobre o banco de dados poderia remover o trigger responsável pela cadeia de hashes e criar um histórico falso coerente; a verificação interna sozinha não detectaria isso. Por isso, um job diário registra o hash final da cadeia fora do próprio banco; os testes comprovam que tanto a verificação interna quanto o mecanismo externo conseguem detectar qualquer alteração indevida.
• O site público ainda não reflete as mudanças planejadas. Até esta data (julho de 2026), o site público ainda exibe alguns textos antigos (um rascunho de licença, informações desatualizadas sobre pagamentos), pois o novo design está apenas em fase de teste, não implementado. Além disso, a URL /about exibe apenas um índice de diretórios; a página de divulgação sobre IA fica um nível abaixo.

Relacionado: a pilha de agentes locais que realizou o trabalho, como esses agentes mantêm meus sites, como configurar seu próprio assistente caso queira reproduzir o mesmo processo, e como fazer com que uma IA adapte qualquer projeto aberto ao seu sistema.