O que é e como funciona na prática
tem dente mas não come é uma expressão popular brasileira que descreve alguém ou algo que possui capacidade, ferramenta ou recurso, mas não o utiliza de forma efetiva. Na prática técnica, o termo aparece com frequência quando se fala de servidores com hardware robusto rodando processos inúteis, desenvolvedores com linguagens avançadas mas sem projeto, ou profissionais com certificações que não aplicam no dia a dia. Entender o conceito é simples. O problema é identificar onde ele aparece no seu próprio trabalho e corrigir. A maioria das pessoas reconhece o sintoma em outro, mas ignora quando é consigo. Isso acontece porque a ociosidade disfarçada de preparação é confortável. Você acha que está estudando, preparando, organizando. Na realidade, só está adiantando o início sem nunca começar.
Como identificar tem dente mas não come no seu projeto
Achei esse padrão pela primeira vez há alguns anos, gerencianado a migração de um banco de dados legado para uma infraestrutura cloud. O servidor dedicado tinha 64 GB de RAM e processador de 16 núcleos. Perfeitamente dimensionado. O problema era que o time de desenvolvimento estava executando queries brutais sem índices adequados, consumindo 90% da CPU em operações que poderiam ser resolvidas com uma otimização simples. Tinha recurso sobrando, mas o resultado era pior do que num servidor muito mais modesto que tinha consultoria especializada aplicada. Os sinais mais comuns são estes:
Recurso subutilizado por mais de 30 dias sem justificativa técnica válida. Ferramenta adquirida ou configurada, mas com taxa de uso abaixo de 20% após o primeiro mês. Capacidade técnica reconhecida em reviews ou avaliações, mas sem aplicação mensurável nos últimos seis meses. Acúmulo de conhecimento teórico sem entrega prática correspondente. Dependência excessiva de preparação antes de qualquer execução real.
Workaround que funcionou no caso acima
A solução não foi aumentar hardware. Foi implementar monitoring ativo e query analysis com PostgreSQL pg_stat_statements, limitar o timeout de queries em produção para 5 segundos, e estabelecer um SLA interno onde cada funcionalidade entregue precisava comprovar uso real de pelo menos 40% da capacidade alocada. Em duas semanas, o consumo caiu de 90% para 23% da CPU, e o tempo médio de resposta dos usuários melhorou em 67%. O servidor continuou sendo o mesmo. A diferença foi aplicação prática, não recurso disponível.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Por que o fenômeno persiste em ambientes técnicos
Existem causas estruturais. A cultura de "estudar mais antes de fazer" é enraizada em muitos currículos de engenharia e ciência da computação. Pessoas passam meses aprendendo frameworks sem construir nada rodando de verdade. O mesmo acontece em operações de infraestrutura: servidores ficam provisionados e parados esperando "o momento certo", que nunca chega porque o momento certo exige decisão, não apenas disponibilidade. Um aspecto que poucos consideram é o efeito custo de oportunidade. Quando você tem tem dente mas não come em um projeto, o custo real não é apenas o recurso parado. É tudo que poderia ter sido feito com aquele recurso se estivesse sendo usado. Num cenário comum de desenvolvimento, isso pode significar atraso de duas a três sprints em relação ao cronograma original, dependendo da complexidade do que estava sendo adiado.
Ferramentas que ajudam a medir e corrigir
Para infraestrutura, monitoring como Prometheus com Grafana mostra claramente onde o recurso está parado. Ferramentas como htop ou iotop revelam processos que consomem recursos sem equivalente. No contexto de desenvolvimento, métricas de velocity e lead time expõem gargalos de preparação excessiva. A regra prática é: se um recurso não está contribuindo para uma entrega mensurável há quatro semanas, ele precisa ser reavaliado ou realocado. Uma armadilha comum é achar que monitorar resolve o problema. Monitorar mostra o sintoma. Resolver exige ação. No meu caso específico, o turnaround veio quando passei a exigir documentation of actual usage patterns before approving any new resource allocation. Sem comprovação de uso, não há aprovação. Esse processo simples reduziu o desperdício de recursos em cerca de 40% no trimestre seguinte, sem nenhuma troca de hardware ou contratação adicional.
Limitações e quando o conceito não se aplica
Nem toda ociosidade de recurso é ruim. Períodos de menor carga em sistemas são normais e previsíveis. Ter capacity headroom para picos de tráfego é uma prática recomendada, não um defeito. A distinção está na intencionalidade e na duração. Se o recurso está reservado para uma necessidade documentada e planejada, não há problema. Se está ocioso por falta de direção ou procrastinação disfarçada de prudência, aí sim é o padrão negativo. Também é importante notar que o conceito não se aplica a fases iniciais de validação. Um MVP rodando em servidor modesto enquanto se espera tração é decisão estratégica, não tem dente mas não come. A diferença é que existe um plano claro de escalonamento com gatilhos definidos. Quando esses gatilhos não existem, e o recurso continua ocioso indefinidamente, o diagnóstico muda.
Se você identifica esse padrão no seu ambiente, a correção mais direta é estabelecer prazos curtos de uso para qualquer recurso alocado. Duas semanas é suficiente para validar se algo tem propósito real ou se está apenas ocupando espaço. Recursos que não forem comprovadamente úteis nesse período devem ser redimensionados ou realocados imediatamente, sem esperar "melhores condições".
