Remova com segurança funcionalidades inventadas em repositórios gerados por IA

O que são funcionalidades inventadas (e por que fazem mal)

Funcionalidades inventadas são partes do código que parecem trabalho real de produto, mas nunca foram requisitos reais. Em repositórios gerados por IA elas costumam aparecer como telas extras, rotas, endpoints de API ou tabelas do banco adicionadas porque a ferramenta supôs o que um "app completo" deveria ter.

Na prática, pode ser uma página de Configurações polida que ninguém alcança, uma API de "admin" que nunca é chamada, ou uma tabela de "subscriptions" em que nada escreve. Tudo compila, mas o recurso não está ligado a necessidades reais de usuário ou fluxos funcionais.

O custo não é só bagunça. Cada página, endpoint e tabela extra aumenta a superfície da sua aplicação. Isso significa mais pontos para bugs, mais formas de vazar segredos e caminhos confusos para quem mantiver o projeto depois.

Funcionalidades fantasmas elevam risco e custo porque elas:

• Aumentam o ruído durante o debug e escondem o problema real.
• Expandem a exposição de segurança via endpoints extras, verificações de auth incompletas e defaults inseguros.
• Tornam alterações mais lentas porque você tem medo de quebrar dependências desconhecidas.
• Enganam decisões de produto porque o repositório sugere capacidades que você na verdade não tem.
• Aumentam trabalho de manutenção (testes, migrations, refactors) por coisas que ninguém usa.

Essas funcionalidades geralmente vêm de scaffolds de IA que geram módulos "padrão", trechos de template copiados, ou threads de prompt onde um recurso foi começado e nunca terminado. Às vezes a ideia fazia sentido, só que nunca foi ligada a uma jornada real do usuário.

O objetivo é simples: manter o que apoia usuários reais e deletar o que não apoia, sem quebrar fluxos críticos. Um cenário comum é um MVP gerado por IA com três telas de login diferentes, dois dashboards de admin e um esquema de billing que não faz nada. Limpar isso torna o app mais fácil de segurar e mais barato de mudar.

Os três tipos principais: páginas mortas, APIs não usadas, tabelas de placeholder

Ao remover funcionalidades inventadas, a maior parte do risco se concentra em três lugares. Elas ficam silenciosas no repo, mas adicionam superfície de ataque, confusão e trabalho futuro.

1) Páginas mortas (rotas inalcançáveis)

Páginas mortas são telas que existem no roteador, mas usuários reais nunca chegam nelas. Costumam aparecer como fluxos abandonados como "Team Settings", "Billing" ou "Admin" gerados cedo e depois esquecidos.

Elas ainda importam porque usuários curiosos podem descobrir, compartilhar, indexar ou abrir diretamente. Mesmo uma página meia pronta pode vazar dados internos, gerar erros ruidosos ou expor flags e pistas do ambiente.

2) APIs não usadas (endpoints sem chamadores reais)

APIs não usadas são rotas do servidor sem chamadores no frontend, ou que só são atingidas por uma página de teste ou script de exemplo. Esses endpoints são fáceis de publicar por acidente, especialmente quando tudo vive numa pasta genérica api.

O perigo não é só código extra. Endpoints não usados frequentemente pulam checagens de auth, aceitam entradas excessivamente amplas ou retornam mais dados do que deveriam — tornando‑os alvos fáceis.

3) Tabelas placeholder (estrutura fictícia no banco)

Tabelas placeholder aparentam progresso, mas muitas vezes são conchas vazias: colunas genéricas, sem constraints, sem índices e sem leituras ou gravações reais no app.

Elas também enganam trabalhos futuros. Alguém vê a tabela e assume que o recurso existe, então constrói em cima dela. É assim que esquemas “temporários” viram dívida permanente.

Outros sinais comuns incluem módulos cheios de TODOs, telas de admin só para demo que pulam permissões, auth fake que aceita qualquer email e arquivos de configuração para serviços que você não usa.

Antes de deletar: decida o que “seguro” significa para seu app

Remover código é seguro só se você concordar sobre o que não pode mudar.

Comece por fluxos chave, não por arquivos. Para a maioria das aplicações, isso é cadastro, login, recuperação de senha, logout e quaisquer ações de dinheiro ou dados como checkout, criação de registros, exportação ou convite de um colega. Se sua equipe depende de uma tela interna de admin todo dia, inclua‑a.

Seja honesto sobre quem usa o app hoje. Usuários pagantes exigem mais cautela. Um demo interno usado por duas pessoas tolera mais mudança. Se ninguém usa ainda, “seguro” pode simplesmente ser: manter o demo funcionando enquanto corta qualquer coisa que aumente risco.

Uma regra simples ajuda a evitar longos debates:

• Remover agora: sem usuários, sem referências, placeholder claro ou risco evidente.
• Arquivar: pode voltar depois, mas não deve rodar em produção.
• Manter mas marcar: usado hoje, mas precisa de dono ou reescrita.

Sua regra de aceitação pode ser direta: "Nenhuma mudança de comportamento nos fluxos chave." Mesmos botões fazem a mesma coisa, mesmas páginas carregam e mesmos dados vão para o mesmo lugar. Se o comportamento precisa mudar, você não está deletando, está redesenhando.

Antes de tocar em algo, prepare rollback. Mantenha um commit conhecido como bom, confirme como redeployá‑lo e decida quem pode aprovar um rollback se algo quebrar.

Como encontrar páginas mortas e rotas órfãs

Páginas mortas existem no repo mas não no produto. Rotas órfãs são URLs que funcionam tecnicamente, mas nada no app aponta para elas.

Comece pelo que um usuário realmente pode clicar. Abra todo menu de navegação, header, footer, sidebar e dropdown de perfil e liste as URLs de destino. Compare isso com a configuração de rotas (arquivos do router, pastas de pages, arrays de rotas). Qualquer coisa nas rotas mas não alcançável pela navegação é um candidato.

Lugares rápidos para olhar:

• Rotas nunca referenciadas por um componente de menu.
• Páginas/componentes que aparecem só em comentários, JSON de mock ou seed data.
• Caminhos "temporários" como /admin, /debug, /test, /demo, /old, /v2, /settings-2.
• Rotas bloqueadas por condições que não acontecem (uma flag sempre falsa, um papel que nunca é atribuído).

Se tiver analytics ou logs de servidor, use‑os como checagem da realidade. Uma rota com zero acessos por semanas é um sinal forte, especialmente se não faz parte de um fluxo de admin. Sem logs, faça um crawl manual: clique nos fluxos principais e depois tente algumas URLs prováveis diretamente.

Exemplo: um MVP gerado por IA pode incluir /team/invite e /billing/upgrade porque o prompt mencionou "SaaS". Se essas páginas não têm links, não têm testes e não têm wiring no backend, normalmente são seguras para remover ou isolar.

Como encontrar endpoints de API não usados ou arriscados

Repositórios gerados por IA muitas vezes vêm com endpoints que pareciam úteis no protótipo mas nunca passaram a fazer parte do produto. Comece montando um inventário e depois prove quem chama cada endpoint.

Primeiro, liste todos os endpoints do backend (arquivos de router, controllers, funções serverless e quaisquer pastas api). Também escaneie configs em busca de rewrites que possam expor handlers.

Depois trace os chamadores. Procure no frontend por fetch ou axios, cheque jobs e filas, e procure handlers de webhook usados por terceiros. Se tiver logs, pesquise pelos caminhos de endpoint nas últimas 1–4 semanas. Ausência de tráfego não é prova perfeita, mas é um indicativo forte.

Antes de deletar, marque endpoints arriscados. Sinais de alerta comuns: rotas de debug acessíveis em produção, bypass de auth (tokens admin hardcoded, userId em query params), CORS aberto em rotas sensíveis, validação ausente e endpoints que retornam segredos ou erros internos detalhados.

Para cada endpoint, escolha um desfecho: deletar, trancar (remover roteamento público, restringir acesso) ou manter e consertar com auth, validação e rate limits.

Como identificar tabelas placeholder e estrutura de banco falsa

Repositórios gerados por IA às vezes vêm com um banco que parece completo mas é em parte imaginário. Tabelas placeholder confundem desenvolvedores, escondem bugs reais e aumentam risco quando esquemas "temporários" passam a guardar dados reais.

Comece listando cada tabela e coluna e depois trace quem realmente as toca. Uma tabela é geralmente real se o app a lê, escreve e tem relacionamentos claros com tabelas centrais (users, orders, projects). Se ela só aparece numa migration e em nenhum outro lugar, trate como suspeita.

Sinais de que uma tabela é placeholder:

• Nomes como sample_*, demo_*, temp_*, test_*, mock_*, staging_*, placeholder_*.
• Sem chaves estrangeiras e sem índices, mesmo quando deveria se relacionar com outras tabelas.
• Colunas genéricas como data JSON, value TEXT, meta TEXT, notes TEXT sem significado claro.
• Dados falsos (lorem ipsum, emails fake, IDs fixos como user_id = 1).
• Duplicatas (duas versões de "subscriptions", "payments" ou "profiles").

Também inspecione migrations por experimentos abandonados: uma migration cria uma tabela, outra cria outra versão e nada limpa a antiga. Se múltiplas tabelas representam o mesmo conceito, diminua o ritmo e verifique qual esquema o app em execução espera.

Quando decidir o que fazer, escolha um caminho: dropar, mesclar ou reconstruir corretamente. Dropar é seguro só depois de confirmar que não há leituras, gravações ou jobs/reporting usando a tabela.

Passo a passo: deletar funcionalidades inventadas sem quebrar o app

Deletar a coisa errada pode quebrar login, permissões ou cobrança. Trate cada recurso suspeito como uma pequena alteração planejada, mesmo quando tiver certeza de que é falso.

Para cada página morta, endpoint não usado ou tabela placeholder, escreva três coisas: o que deve acontecer depois da remoção, como você verificará que nada importante dependia dela e quem pode aprovar a decisão.

Uma ordem de operação de baixo risco:

• Remova páginas e UI ocultas primeiro.
• Remova handlers de API não usados em seguida (mais helpers que existem só para aquela feature).
• Limpe o banco por último (migrations, modelos do ORM, cron jobs).

Após cada remoção, construa o app, rode testes se houver e percorra os fluxos principais manualmente. Reavalie também as fronteiras de autenticação — é possível remover código de um modo que acabe ignorando um middleware ou alterando uma checagem de permissão.

Erros comuns que causam quebras ou problemas de segurança

Quebras normalmente acontecem quando o repo parece limpo no navegador, mas partes ocultas ainda rodam em produção. Pense no que pode ser chamado sem clicar: jobs, webhooks, tarefas cron e requisições HTTP diretas.

Uma armadilha comum é deletar uma página ou botão e deixar a API viva. A tela de admin pode ter sumido, mas o endpoint ainda aceita requisições. Se o auth for fraco, esse endpoint vira ponto de ataque.

Outro erro é assumir que um endpoint não é usado porque não está linkado na UI. Workers de background, tarefas agendadas e integrações de terceiros ainda podem chamá‑lo. Exemplo: você deleta /api/email/weekly-summary porque não está em nenhuma página, mas um job noturno ainda o chama, começa a falhar e gera retries e logs ruidosos.

A limpeza do banco é onde as pessoas perdem dados. Dropar tabelas "placeholder" sem checar backups, ordem de migrations e uso em produção pode quebrar deploys ou apagar registros que depois foram reutilizados.

Antes de deletar, verifique:

• Você removeu o acesso, não só a UI (rotas/controllers não estão publicamente alcançáveis).
• Você buscou uso em jobs/workers e chamadas de terceiros.
• Validou backups e sequenciamento de migrations.
• Removeu rotas de debug, chaves de teste e logins admin temporários da produção.

Checklist rápido antes de remover qualquer coisa

Antes de deletar código, confirme que você não está tirando algo que sustenta um fluxo.

Comece pela alcançabilidade. Se um usuário normal não alcança a página por cliques normais (não digitando uma URL escondida), é um forte candidato. Ainda assim, confirme que você não está cortando um caminho lateral como onboarding, reset de senha ou setup de admin.

Checagens rápidas:

• Um usuário normal pode alcançá‑la sem URLs especiais, contas de teste ou toggles dev‑only?
• Se for um endpoint, está protegido (auth) e guardado (validações básicas, rate limits) ou está aberto demais?
• Se toca dados, você encontra um caminho de código real que leia ou escreva nessa tabela em produção?
• Removerá isso mudanças em papéis, permissões, convites, acesso à cobrança ou passos de onboarding?
• Você removeu segredos, chaves de exemplo e configs só de teste que vieram junto?

Planeje um rollback rápido. Mesmo deleções cuidadosas podem quebrar builds, migrations ou jobs. Marque um release, mantenha commits limpos e certifique‑se de que dá para redeployar a versão anterior rapidamente.

Exemplo: limpando um MVP gerado por IA com features extras

Um fundador lança um MVP gerado por IA. Ele funciona para o fluxo central (signup, criar projeto, fazer upload de arquivo), mas o repo também contém "Teams" e "Billing". Ninguém pediu por isso, ninguém usa, mas ainda adicionam rotas, endpoints e tabelas que podem causar problemas depois.

O primeiro passo é provar que são inventadas, não apenas escondidas. Procure evidências de uso real:

• Nenhum link ou botão leva às páginas (só funcionam por URL direta).
• Logs de backend não mostram chamadas para os endpoints relacionados em sessões reais.
• O frontend nunca chama as APIs.
• Tabelas do banco estão vazias ou só com seed data.
• Código cheio de copy placeholder como "TODO", "Coming soon" ou planos falsos.

Quando tiver confiança, remova a superfície em ordem segura: UI primeiro, API depois, esquema por último. Se não estiver pronto para deletar tudo, mantenha um stub claramente rotulado (por exemplo, uma página inócua dizendo "Billing não disponível ainda") e evite deixar endpoints meio construídos ou escritas de banco incompletas.

O resultado é imediato: menos partes móveis, superfície de ataque menor, revisões de código mais rápidas e um roadmap mais claro do que o app realmente faz.

Próximos passos: manter o repositório limpo e reduzir risco ao longo do tempo

Deletar funcionalidades inventadas é um ganho. Impedir que voltem é o maior lucro.

Mantenha um backlog pequeno de limpeza para tudo que você não deletou ainda. Anote por que ficou ("pode ser usado depois", "precisa de decisão de produto", "bloqueado por falta de testes") e adicione uma ação clara. Isso evita que scaffolding temporário vire dívida permanente.

Algumas regras leves ajudam:

• Fazer o CI falhar em placeholders óbvios (rotas TODO, chaves de exemplo, flags de demo).
• Exigir que cada nova página e endpoint tenha uma nota de uso ou um teste.
• Revisar rotas/endpoints não usados no staging periodicamente.
• Manter uma allowlist curta de tabelas e migrations reais, e sinalizar tudo que estiver fora dela.

Se o repositório está bagunçado, não comece deletando arquivos aleatoriamente. Mapeie primeiro o que é alcançável na UI, o que é alcançável pela rede e quais dados são realmente usados. Esse mapa evita o clássico erro de remover uma funcionalidade “morta” que estava sustentando auth, cobrança ou onboarding de forma silenciosa.

Se você herdou um protótipo gerado por IA e quer um plano estruturado de desmontagem, FixMyMess (fixmymess.ai) foca em diagnosticar e reparar codebases geradas por IA, incluindo identificar páginas mortas, endpoints arriscados e esquemas placeholder antes de cortar qualquer coisa.