A origem

Uma empresa mais consciente, conectada e capaz de aprender com a própria operação.

Informações

ē.43 · A noite em que decidi apagar dez tabelas
Tudo é entidade

ē.43 · A noite em que decidi apagar dez tabelas

Carlos Eduardo Tobias

9 de agosto de 2026
Parte 43

Construir é adicionar. Qualquer um gosta. A parte que ninguém conta é que a decisão mais difícil de um sistema é a de tirar.

Sobre dez tabelas apagadas num sábado, o medo que tem nome técnico, e por que tirar é sempre mais caro do que manter.

Era sábado. Eu me lembro porque a rua estava quieta de um jeito que só fica no fim de semana, e porque eu tinha dito para mim mesmo que ia só olhar o problema.

Nunca é só olhar.

01O comando

A operação era simples de escrever e difícil de executar.

Dez tabelas. A família inteira de módulos, mais agentes, prompts, skills, produtos e tarefas no formato antigo. Tudo aquilo que o grafo já sabia representar, e que continuava existindo em paralelo porque um dia foi mais fácil deixar.

Apagar.

Eu escrevi o comando e fiquei olhando para ele.

Essa é a parte que não aparece em nenhuma documentação de arquitetura: o tempo que você passa com o dedo parado.

Porque adicionar é reversível. Você cria uma tabela nova, não gostou, apaga. Nada se perde.

Tirar é diferente. Tirar é uma afirmação. Você está dizendo: eu sei o suficiente sobre esse sistema para garantir que ninguém precisa mais disso.

E você nunca sabe o suficiente.

02O medo tem nome técnico

O medo de apagar não é irracional. Ele tem uma forma bem específica, e é a seguinte:

Não é que a tabela vá fazer falta. É que alguma coisa lê dela e você não sabe o quê.

Numa base com centenas de arquivos, dezenas de telas, agentes, automações e rotinas, a pergunta "quem usa isso?" não tem resposta curta. Tem resposta provável.

E resposta provável, às duas da manhã, é a mesma coisa que resposta nenhuma.

Então você faz o que dá:

  • procura cada nome de tabela em todo o código
  • procura em quem lê o banco direto
  • procura nas automações
  • procura nos documentos
  • e depois procura de novo, porque a primeira busca foi com pressa.

E no fim, depois de todas as buscas, ainda sobra um resto de dúvida que nenhum método resolve. Esse resto é o trabalho.

O que fica depois de tirar: alicerce limpo, terreno livre.
um platô de pedra clara ao sol, onde se veem os ALICERCES retangulares vazios de construções que já não existem, lado a lado, limpos e varridos; o terreno em volta aberto e livre. Muito céu limpo acima.

03O que eu decidi, e por quê

Decidi que não haveria fallback.

Essa foi a parte que me custou mais. O instinto manda deixar uma saída: mantém a tabela desativada, mantém um espelho de leitura, mantém um "por via das dúvidas".

Mas eu já tinha aprendido, no texto anterior, o que o "por via das dúvidas" vira: um espelho novo, com outro nome.

Então a regra foi dura e proposital: se algum código tentar ler aquelas tabelas, ele está errado por definição. Não existe caminho alternativo. Não existe degradação graciosa.

Isso parece radical e é a parte mais honesta da operação. Um sistema que tem duas respostas vai, mais cedo ou mais tarde, dar as duas.

04Maquiavel tinha um ponto, e não é o que dizem

Maquiavel é lembrado pela frase que ele não escreveu daquele jeito, sobre fins e meios.

A parte que me interessa é outra. Ele observa que quem assume algo novo tem contra si todos os que se davam bem no arranjo antigo — e tem a favor apenas os que ainda não experimentaram o novo o suficiente para defendê-lo.

Em software isso é literal.

Cada estrutura velha tem um partido: o código que a usa, a tela que a lê, a rotina que depende dela, e o hábito de quem construiu. Tudo isso vota contra a mudança, em silêncio, na forma de risco.

A estrutura nova não tem partido nenhum. Ela ainda não provou nada.

E por isso quase todo sistema vira um acúmulo. Não porque alguém decidiu acumular — porque tirar exige uma decisão e manter não exige nenhuma.

Ficar parado é sempre a escolha mais barata no curto prazo. Essa é a frase mais importante que eu aprendi naquele sábado.

05O que ficou depois

Dez tabelas a menos. Uma fonte de verdade.

Nenhuma tela ficou mais bonita. Nenhum cliente percebeu. Não dava para escrever um post de lançamento — "removemos coisas" não é manchete.

Mas toda decisão depois daquela ficou mais barata.

Porque é isso que a fonte única compra: não velocidade, não beleza. Previsibilidade. A próxima pergunta sobre um módulo passou a ter um único lugar para ser respondida.

E quando o grafo cresceu de verdade nos meses seguintes — muito, muito mais do que naquele agosto — ele cresceu sem carregar a dívida junto.

Se eu não tivesse apagado naquele sábado, cada uma das dezenas de milhares de entidades que vieram depois teria nascido com a pergunta: e a cópia?

06O ruído de fora

Foi mais ou menos nessa semana que a corrida de modelos ficou absurda.

Entre o começo e o fim daquele mês saíram doze modelos novos em vinte dias. Google, xAI, os chineses, todo mundo publicando em cima de todo mundo. Um Gemini novo no dia treze. Grok. GLM.

E eu, num sábado à noite, apagando tabela.

Tem uma desproporção cômica nisso que eu acho que vale registrar. O mundo inteiro anunciando capacidade nova, e o trabalho que realmente destravou o meu projeto foi remover coisa.

Nenhum modelo novo resolve duas fontes de verdade. Nenhum.

Modelo melhor com arquitetura confusa dá resposta confusa mais rápido.

Uma última pergunta
Qual é a coisa que você mantém no seu negócio hoje só porque desligar dá trabalho — e quanto ela te cobra, em silêncio, toda vez que você muda alguma coisa?

Esta série acompanha as perguntas, tecnologias, erros e ideias que foram transformando a archē de uma estrutura de organização em um sistema de contexto.

Comentários

Ainda não há comentários por aqui. O primeiro pode ser o seu.

Deixe o seu