Nem tudo que pode ser automatizado deveria ser. A regra de decisão que rodo antes de construir qualquer workflow, e as quatro automações que deletei depois que elas funcionaram perfeitamente.
Já deletei mais automações do que as que rodo atualmente. Não porque quebraram, mas porque funcionaram perfeitamente e pioraram as coisas.
Essa frase merece atenção, porque é o que a turma do “automatize tudo” nunca aborda. Uma automação que roda de forma confiável e degrada a qualidade do seu trabalho não é uma vitória de produtividade. É um passivo disfarçado de ativo. O único sinal que capta isso é perceber, semanas depois, que os outputs que você está produzindo pioraram silenciosamente, e que a automação estava mascarando essa decadência.
Esta é a regra de decisão que rodo antes de construir qualquer coisa. É uma única pergunta com três subverificações, e ela já me economizou mais tempo do que a maioria das automações que eu teria construído sem ela.
Construí quatro automações que depois deletei. Todas as quatro funcionaram. Aqui está o que faziam e por que foram embora.
Resumos automáticos de notas de reunião. Um modelo rodando sobre cada transcrição de reunião, resumos instantâneos enviados trinta minutos após cada call. O problema: os resumos eram precisos e inúteis. Notas de reunião precisam de curadoria, não compressão. A automação mostrava o que foi dito na proporção de quanto foi dito. O que realmente importava na maioria das reuniões era uma frase falada uma única vez, de forma hesitante, que eu tinha anotado e em torno da qual construiria o brief. Essa frase não se destacava num resumo. Parecia igual às outras quarenta e nove frases. A automação produzia documentação limpa e bem formatada das partes menos importantes de cada reunião.
Substituído por: o sistema de anotação com três tags. Manual. Não automatizável.
Rascunhos automáticos de follow-up com clientes. Um modelo redigindo e-mails de follow-up a partir do resumo da reunião. O problema: aplicava um registro profissional uniforme a relações que exigiam tratamentos diferenciados. Um cliente queria brevidade e diretividade. Outro precisava de calor e contexto. Outro estava numa posição politicamente sensível que exigia enquadramento cuidadoso. O modelo produzia follow-ups corretos, fluidos, profissionais. Estavam errados para a relação da mesma forma que um cartão de pêsames pré-escrito está errado: gramaticalmente correto, situacionalmente deslocado. Três clientes responderam num tom que deixava claro que tinham sentido a ausência de uma pessoa real do outro lado. A automação estava tecnicamente correta; os outputs estavam profissionalmente errados.
Substituído por: nada. Alguns follow-ups têm que ser escritos à mão.
Digests de briefing. Um digest diário de tudo marcado como importante nas minhas notas da semana anterior. O problema: o hábito dos digests diários me tornou menos seletivo sobre o que eu marcava como importante. Quando um sistema vai agregar tudo, você perde a disciplina de decidir o que importa antes de capturar. O digest acumulava. Abrangência substituiu seletividade, e seletividade era o ponto.
Substituído por: uma revisão manual semanal de quinze minutos das notas brutas da semana. Escolho as três coisas que de fato moveram algo. Essa restrição é estrutural.
Scores de confiança. Pedi ao modelo para avaliar seus próprios outputs de pesquisa numa escala de confiança de 1 a 10. O problema: os números eram fabricados. O modelo fazia pattern-matching do que um score de confiança parece e produzia números plausíveis. Eu me deixava guiar por eles. Tinha automatizado a mímica do julgamento e confundido isso com o julgamento em si.
Substituído por: minha própria marcação de incerteza. Quando não tenho certeza de que algo está certo, escrevo “CHECK:” antes. Quando tenho certeza, escrevo a afirmação. Esse sistema é binário e honesto. Não custa nada.
As quatro foram deletadas não porque quebraram, mas porque estavam otimizando eficiência em lugares onde eficiência não era a restrição limitante.
Antes de construir qualquer automação, rodo uma pergunta:
O gargalo dessa tarefa é o tempo que ela leva, ou o julgamento que ela exige?
Se a resposta é tempo, vale considerar automação.
Se a resposta é julgamento, vale evitar automação, ou pelo menos garantir que a etapa que contém julgamento seja a única coisa que a automação não toca.
Três subverificações decorrem disso:
Subverificação um: como é a falha, e com que rapidez ela aparece? Algumas falhas são óbvias e rápidas: a automação quebra, nada funciona, você percebe imediatamente. Outras falhas são invisíveis e lentas: a automação roda, produz um output plausível, e degrada a qualidade ao longo de semanas. As lentas são piores. Antes de construir, pergunto: se essa automação produzir um output ruim silenciosamente, quanto tempo vou levar para perceber? Se a resposta for “mais de uma semana,” quero um checkpoint humano antes do output ser usado, não depois.
Subverificação dois: estou automatizando a representação do trabalho, ou o trabalho em si? Essa é a distinção mais importante que encontrei, e é fácil de perder porque um bom output de IA parece um bom trabalho. Formatar um brief, redigir um resumo, estruturar um documento: essas são representações de pensamento, não pensamento. Automatizá-las é de baixo risco se o pensamento subjacente for seu. Mas se a automação produz a representação antes do pensamento ter acontecido, você obtém algo que parece completo e não é. A automação que devo construir é a que formata o output depois que já fiz o trabalho de julgamento. A que devo evitar é a que produz o output em vez dele.
Subverificação três: essa tarefa é cumulativa? Algumas atividades ficam mais valiosas quanto mais você as faz repetidamente: você desenvolve reconhecimento de padrões, constrói conhecimento de relacionamento, refina um modelo da situação de um cliente. Se você automatiza uma atividade cumulativa, para de acumular. A máquina roda as repetições e você não. Ao longo de um ano, a diferença é significativa. Ao longo de três anos, é a diferença entre alguém com uma visão genuinamente profunda do próprio domínio e alguém com boas ferramentas. Mantenho nas minhas mãos tudo que é cumulativo.
Para deixar claro: automatizo muita coisa. Essa regra não produz um cético que faz tudo à mão. Ela produz especificidade sobre onde a automação entra.
Automatizo formatação e estrutura. Automatizo compressão de material que já curei e anotei. Automatizo recuperação: construo sistemas que trazem pensamentos passados sob demanda. Automatizo agendamento e roteamento: a camada administrativa de qualquer workflow que é puramente sobre mover coisas de um lugar para outro.
Não automatizo a primeira articulação da minha posição sobre nada. Não automatizo o tratamento de relacionamentos. Não automatizo a etapa que exige que eu decida o que importa. E não automatizo nada cujo modo de falha seja soar confiante e estar errado, porque esse modo de falha é invisível até deixar de ser.
A pergunta nunca é “isso pode ser automatizado?” É “qual é o custo real se isso produzir uma resposta plausível e errada, e quem percebe?”
Mantenho um documento curto, um log de decisões, onde registro toda automação que considerei e não construí, e por quê. Tem cerca de duas dezenas de entradas. É, genuinamente, mais útil do que a lista de automações que rodo, porque as entradas contêm o raciocínio de por que uma dada tarefa é trabalho de julgamento, e esse raciocínio se transfere para novas decisões. Toda vez que sou tentado a construir algo para uma tarefa parecida, checo o log primeiro.
A decisão de não automatizar é tão deliberada quanto a decisão de automatizar. Tome-a de propósito, documente-a, e ela deixa de ser uma oportunidade perdida. Vira política.
Esse documento, a matriz de decisão de ferramentas e o formato de log de decisões que uso, está disponível como template. A lógica no formulário é a mesma lógica que descrevi aqui; o template a torna reutilizável em decisões recorrentes.
→ Tool Decision Framework — $39. Matriz de decisão estruturada + formato de log de decisões. Solte no Obsidian ou Notion. (Enviando primeiro para a lista da newsletter; inscreva-se abaixo.)
Quatro automações deletadas. Cada uma ensinou algo que a comunidade do “construa primeiro” não diz em voz alta: a pergunta não é se você pode automatizar. É se, daqui a dois meses, você vai ficar feliz por ter feito.
A seguir em Systems → Como mantenho os outputs de IA honestos, as verificações que rodo antes de qualquer coisa ir para um cliente.
O template exato do Obsidian e a cadeia de prompts completa — a nota de intake estruturada, o prompt de contraste e o checklist de provocação. Coloque no seu vault e rode seu próximo prospect nele em quarenta minutos.
Sem cronograma. Sem enchimento. Sem posicionamento patrocinado. Uma nova construção só sai quando vale seus dez minutos — geralmente a cada 2–4 semanas.
"Só vou enviar algo que eu teria escrito mesmo que ninguém me pagasse por isso. No dia em que isso parar, a newsletter para."